748 字
4 分钟
Bangumi MCP: A Lightweight HTTP MCP Service
TIP

The project is open-sourced at Tokisaki-Galaxy/bangumimcp-ts. Feel free to star it.

NOTE

Do not use third-party MCP servers for sensitive accounts. If you need to write collections or handle personal data, self-hosting is safer.

If you want to connect Bangumi to MCP-capable clients such as Claude, Cursor, or Copilot, the hard part is often not the connection itself. The real problem is too many tools, which makes it harder for the model to choose the right one.

This project takes a simple approach. It wraps the Bangumi API into an HTTP MCP service deployable on Cloudflare Workers, then reduces dozens of fine-grained endpoints into 8 tools that are easier for the model to understand.

Why I turned it into MCP#

Bangumi is a very rich service. It has entries, people, characters, collections, indexes, episodes, and revision history. The API surface is broad and capable.

That also creates two problems for LLMs.

  1. It is easy to pick the wrong tool
  2. Too many tool descriptions can fill the context window

So the goal here is not to expose every endpoint as-is. The goal is to group common actions so the model can understand the intent first, then call a specific tool.

How to use it#

Add the MCP server URL directly in your MCP client.

https://bgm.api.tski.uk/mcp

If you want to write collections, update progress, or favorite people and characters, you also need a personal access token.

https://next.bgm.tv/demo/access-token/create

Deployment#

One-click deploy#

deploy

Deploy by forking#

Fork Tokisaki-Galaxy/bangumimcp-ts to your own account, then connect the repository in Cloudflare.

Requirements#

  • A Cloudflare account
  • A GitHub repository connection

The 8 exposed tools#

By default, this MCP exposes only these 8 entry points.

  • search
  • get_subject
  • get_user
  • get_calendar
  • update_collection
  • get_person
  • get_character
  • manage_index (disabled by default)

One tool for three object types: entries, people, and characters.

It supports scope to limit the search range, plus pagination and filter parameters. The usual flow is to search first, then expand details later if needed.

get_subject#

This is the entry tool for subject details. It returns more than a title and summary.

It can also expand these sections through include:

  • persons
  • characters
  • relations
  • episodes

That means the model can fetch main data and related data in one call.

get_user#

This is the user profile tool.

It returns user data and a collection snapshot, which is useful for understanding what a user usually watches, collects, or prefers.

get_calendar#

This is the broadcast calendar tool.

If you want to check what is airing today or this week, this is the most direct entry point.

update_collection#

This is the only write tool.

I intentionally grouped “collect an entry,” “update progress,” “favorite a person,” and “favorite a character” into one tool, then route them strictly by target_type.

  • target_type=subject can use subject_status / progress / rating / comment
  • target_type=person or target_type=character can only use favorite

This avoids mixing unrelated parameters.

get_person#

This is the person detail tool. It also returns related works and character information.

get_character#

This is the character detail tool. It also returns works and voice actor related information.

manage_index#

This is the index management tool, but it is disabled by default.

It appears in the tool list only after the environment variable is enabled.

Why the tool set was reduced#

The point is not to remove features. The point is to reduce cognitive cost.

For the model, fewer tools are easier to choose from. For people, fewer entry points are easier to remember.

Before this change, the service could have exposed tools like:

  • get_subject_details
  • get_subject_persons
  • get_subject_characters
  • get_subject_relations
  • get_episodes

Now they are folded into a single get_subject, and include decides which expanded data to return.

That matters for MCP, because MCP is not mainly for writing scripts. It is for model calls.

A few implementation details#

Partial failures do not break the whole call#

Aggregated tools such as get_subject, get_user, get_person, and get_character fetch multiple sub-resources in parallel.

If one sub-request fails, the whole call does not fail. That section is returned as _error instead.

The model can still use the rest of the data.

Write parameters are validated strictly#

update_collection no longer tries to guess your intent.

If the parameter combination is invalid, it returns invalid_argument.

That is important for LLMs. Silent fallback makes the model believe the write already succeeded.

nsfw_filter is passed through normally#

When searching characters without a token, Bangumi itself ignores the NSFW filter instead of raising an error.

So this MCP passes the parameter through unchanged and lets the backend handle permissions.

Good use cases#

  • Query Bangumi entries with natural language
  • Ask the model to summarize people, characters, and entry relationships
  • Check collection status and the broadcast calendar quickly
  • Keep client-side tool selection stable with fewer tools

Closing#

The direction of this Bangumi MCP is very clear.

Small, stable tools with clear semantics.

It does not expose the whole Bangumi API to the model. It groups common actions into a more conversational Bangumi front door.

If the goal is to make AI access Bangumi in a practical way, this kind of reduced tool design is usually more effective than exposing every endpoint.

Bangumi MCP: A Lightweight HTTP MCP Service
https://tski.uk/blog/en/mcp-bangumi/
作者
Tokisaki Galaxy
发布于
2026-04-24
许可协议
CC BY