Provides tools for searching anime and manga, fetching details, rankings, seasonal anime, public user lists, and managing the authenticated user's anime and manga list entries through the MyAnimeList API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MyAnimeList MCP Server Search for anime titled 'Frieren' and show its synopsis."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Search, inspect, rank, and manage MyAnimeList anime and manga from any MCP-compatible AI client.
MyAnimeList MCP Server is a Python MCP server for the MyAnimeList API. It uses MCP SDK v2, keeps stdio as the default transport, and exposes the MAL API through typed tools that work with Claude, Codex, Gemini, and other MCP clients.
Public tools work with a MAL client ID. Authenticated tools use OAuth and can either open a local browser flow or use a refresh token in headless environments.
15 tools for anime, manga, rankings, seasonal releases, public lists, and the authenticated user profile.
MCP SDK v2 with stdio transport and protocol compatibility for existing clients.
One reusable async HTTP client per server lifespan.
Explicit timeouts, bounded retries for safe GET requests, connection limits, and sanitized errors.
MAL OAuth with PKCE plain mode, state validation, localhost callback handling, token reuse, and concurrency locking.
Memory-only access and refresh tokens; no token persistence files.
Docker image built from the locked dependency graph with uv.
Related MCP server: MyAnimeList MCP Server
The server starts an MCP stdio process. Each tool call is translated into a MyAnimeList API request through the shared client. Public requests use the MAL client ID; authenticated requests add a bearer token obtained from the in-memory OAuth manager.
Successful responses preserve the MAL response shape. Error responses use a stable error field and, when available, status_code, without returning raw response bodies, URLs, authorization codes, or tokens.
Python 3.12 or newer
A MyAnimeList API client ID
A MyAnimeList client secret for authenticated tools
Docker, only if you want to run the container image
Clone the repository and install the locked environment:
git clone https://github.com/MorpKnight/myanimelist-mcp.git
cd myanimelist-mcp
cp .env.example .env
uv sync --lockedEdit .env and set at least MAL_CLIENT_ID. Add MAL_CLIENT_SECRET before using authenticated tools.
Run the server:
uv run --locked main.pyThe default transport is stdio. stdout is reserved for MCP messages; OAuth diagnostics are sent to stderr.
Create an application from MyAnimeList API Config.
Use these values as a starting point:
App Description: An open-source MCP server for searching and managing MyAnimeList data from AI clients.
App Redirect URL: http://127.0.0.1:8080/callback
Homepage URL: https://github.com/MorpKnight/myanimelist-mcp
Copy the generated client ID and client secret into .env. The redirect URL must exactly match the URL registered in MAL.
Add this entry to claude_desktop_config.json and replace the project path:
{
"mcpServers": {
"myanimelist": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/myanimelist-mcp",
"run",
"--locked",
"main.py"
]
}
}
}Keep .env in the project directory so the server can load it when started with --directory.
Use the same command in the client's MCP server configuration:
uv --directory /absolute/path/to/myanimelist-mcp run --locked main.pyMCP clients can use different configuration wrappers, but discovery, schemas, and tool calls use the same MCP protocol.
The repository includes a stdio smithery.yaml manifest. The manifest can be published under the project's own Smithery namespace when that namespace is available. No upstream Smithery namespace is assumed by this repository.
Build the image:
docker build -t myanimelist-mcp .Run it as an MCP stdio server:
docker run --rm -i --env-file .env myanimelist-mcpThe image installs dependencies with uv sync --locked and does not include .env, tests, Git metadata, or local caches.
Variable | Required | Default | Description |
MAL_CLIENT_ID | Yes | — | MyAnimeList API client ID. |
MAL_CLIENT_SECRET | OAuth | — | MyAnimeList OAuth client secret. |
MAL_REFRESH_TOKEN | No | — | Refresh token for headless authenticated deployments. |
MAL_API_URL | No | MAL API base URL. | |
MAL_OPEN_BROWSER | No | true | Open the browser for interactive OAuth. |
MAL_CALLBACK_HOST | No | 127.0.0.1 | Loopback host for the OAuth callback. |
MAL_CALLBACK_PORT | No | 8080 | Local OAuth callback port. |
MAL_CALLBACK_TIMEOUT | No | 300 | OAuth callback timeout in seconds. |
Keep.env private. Access tokens and refresh tokens are held in memory only, but the values in .env still grant access to your MAL application or account.
For a deployment without a browser, set a valid refresh token and disable interactive browser opening:
MAL_REFRESH_TOKEN=your_refresh_token
MAL_OPEN_BROWSER=falseRefresh tokens are never written back to disk by this server.
Tool | Auth | Purpose |
get_anime | Public | Search anime by query. |
get_anime_details | Public | Fetch details for an anime ID. |
get_anime_ranking | Public | Fetch anime rankings. |
get_seasonal_anime | Public | Fetch anime for a season and year. |
get_anime_list | Public | Fetch a user's public anime list. |
get_suggested_anime | OAuth | Fetch suggestions for the authenticated user. |
update_myanimelist | OAuth | Update an anime list entry. |
delete_myanimelist_item | OAuth | Delete an anime list entry. |
Tool | Auth | Purpose |
get_manga | Public | Search manga by query. |
get_manga_details | Public | Fetch details for a manga ID. |
get_manga_ranking | Public | Fetch manga rankings. |
get_manga_list | Public | Fetch a user's public manga list. |
update_mymangalist | OAuth | Update a manga list entry. |
delete_mymangalist_item | OAuth | Delete a manga list entry. |
Tool | Auth | Purpose |
get_user_profile | OAuth | Fetch the authenticated user's profile. |
Install all locked dependencies, including the development group:
uv sync --lockedRun linting and tests:
uv run --locked ruff check .
uv run --locked pytest -qThe default suite uses mocked HTTP responses, MCP in-memory tests, OAuth callback tests, and stdio subprocess tests. It does not mutate a real MAL account.
Set MAL_CLIENT_ID in .env or in the MCP client's process environment, then restart the client.
Stop the process using port 8080, or choose another loopback port and register the matching redirect URL in MAL:
MAL_CALLBACK_PORT=18080Use MAL_OPEN_BROWSER=true for interactive authorization. For headless use, provide MAL_REFRESH_TOKEN and set MAL_OPEN_BROWSER=false.
Start the server with the stdio command above. Do not add application prints to stdout; stdout must contain only MCP protocol messages.
Check the client ID, client secret, refresh token, redirect URL, and callback port. If the refresh token is expired or revoked, run the interactive flow again.
Project policies and attribution are documented in CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, and NOTICE.md.
Delete one anime from the authenticated user's MAL list.
| Name | Required | Description | Default |
|---|---|---|---|
| anime_id | Yes | MyAnimeList anime ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Delete' but does not mention that the action is permanent, what happens if the anime isn't on the list, or any specific authentication requirements beyond the phrase 'authenticated user's.' For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler or redundancy. It earns its place by stating the exact action and target in the fewest words possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description covers the core action and implies authentication, but it omits side effects and error cases. It is minimally adequate given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond what the schema provides for anime_id. The baseline of 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'anime' and scope 'authenticated user's MAL list,' clearly distinguishing it from sibling get/update tools. It is immediately obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you want to remove an anime from the authenticated user's MyAnimeList. It doesn't explicitly exclude alternatives, but the sibling names (e.g., delete_mymangalist_item, update_myanimelist) make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one manga from the authenticated user's MAL list.
| Name | Required | Description | Default |
|---|---|---|---|
| manga_id | Yes | MyAnimeList manga ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It states the delete action but does not disclose irreversibility, authentication prerequisites, error behavior, or side effects. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words or redundant details. It front-loads the essential information and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description is minimally sufficient but lacks context about success/error responses, prerequisites, or idempotency. The absence of an output schema and the sparse behavioral detail prevent it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description for manga_id ('MyAnimeList manga ID'). The tool description adds no additional parameter meaning, so based on the high schema coverage baseline, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete one manga from the authenticated user's MAL list.' It uses a specific verb ('delete') and resource ('manga from authenticated user's MAL list'), and the mention of 'manga' distinguishes it from the sibling tool delete_myanimelist_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or alternatives. The name and description imply the purpose, but no explicit usages or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MyAnimeList anime by title or another text query.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| limit | No | Number of results | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It merely states 'Search MyAnimeList anime' without addressing read-only nature, pagination behavior, rate limits, or handling of no results. The schema reveals limit/offset, but the description does not explain these behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word adds value with no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and complete parameter schema, the description is minimally sufficient for basic use. However, without an output schema or annotations, it does not clarify what the search returns (e.g., list format, pagination details) or how it fits with sibling tools, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so q ('Search query'), limit ('Number of results'), and offset ('Pagination offset') are all documented. The description's 'by title or another text query' adds only a minor clarification for q and does not provide additional semantics beyond the schema, hence a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and clearly identifies the resource 'MyAnimeList anime' as the target. This distinguishes it from sibling tools like get_anime_details (which retrieves specific details) and get_anime_ranking (which retrieves rankings), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is to be used when the agent has a title or text query to search for anime. However, it provides no direct guidance on when not to use it or when to prefer sibling tools like get_anime_details or get_anime_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details for one anime, optionally selecting MAL response fields.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| anime_id | Yes | MyAnimeList anime ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It only indicates a read operation ('Fetch') but does not explain return format, pagination, permissions, rate limits, or side effects. The optional 'fields' hint is the only extra detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately short for a simple tool, though the brevity sacrifices useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and relies on the description for completeness. However, the description does not explain what 'details' are included, what fields are available, or how it differs from 'get_anime'. This makes it incomplete for an agent deciding whether and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal descriptions for both parameters ('MyAnimeList anime ID' and 'MAL response fields'). The description adds that field selection is optional but fails to explain what valid 'MAL response fields' are, leaving agents to guess. Schema coverage is only 50%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('details for one anime'), and mentions the optional 'fields' selection. However, it does not distinguish itself from the sibling tool 'get_anime', leaving potential ambiguity about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_anime' or 'get_anime_ranking'. It does not describe context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an anime list for a MAL user.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| status | Yes | ||
| username | Yes | MyAnimeList username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but there is no mention of authentication requirements, rate limits, pagination behavior, error handling, or what the response contains. The description is too sparse to convey meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of eight words. Every word contributes meaning, and it is appropriately front-loaded with the core action and target. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too minimal. It fails to convey pagination options, sorting behavior, status filtering, or return value expectations. The description is a bare minimum and leaves significant gaps for an agent to navigate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. The input schema covers 60% of parameters (limit, offset, username have descriptions), but status and sort lack explanations beyond their enum values. Since the description adds no semantic context for these parameters, the overall parameter semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an anime list for a MAL user' uses a specific verb ('Fetch') and resource ('anime list') with a clear scope ('for a MAL user'), which distinguishes it from sibling tools like get_anime_ranking or get_manga_list. It fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context for choosing it over other list/ranking tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch anime rankings using MAL's ranking_type query parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| ranking_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action and mentions the ranking_type query parameter, but does not disclose pagination behavior, return format, authentication requirements, or any potential side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and resource. It contains no fluff or redundant information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values, ordering, pagination, or authentication. None of these are mentioned. The description provides only a minimal overview, leaving significant gaps for an agent relying on it alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (limit and offset have descriptions), and ranking_type has an enum. The description adds minimal value by mentioning ranking_type but does not explain its possible values or how it influences results. This aligns with the baseline for moderate schema coverage where the schema handles most parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches anime rankings, which is a specific verb+resource pair. However, it does not explicitly distinguish this from sibling tools like get_manga_ranking or get_seasonal_anime, though the resource name provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or contrasting sibling tools, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MyAnimeList manga by title or another text query.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| limit | No | Number of results | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the search function and offers no details on pagination, result ordering, or output structure. There is no mention of side effects or limitations, leaving significant room for misjudgment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core purpose, matching the standard of high-conciseness examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and sparse annotations, the description should explain what the search returns. It does not mention result format or list properties, leaving the agent under-informed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal nuance by clarifying 'q' is a title or text query, but this is a minor enhancement over the schema's 'Search query'. It does not elaborate on limit or offset behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('MyAnimeList manga'), clearly indicating this is a search tool. It distinguishes from siblings like get_manga_details or get_manga_ranking, but doesn't explicitly contrast with get_manga_list, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or when get_manga_list or get_anime would be more appropriate, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details for one manga, optionally selecting MAL response fields.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| manga_id | Yes | MyAnimeList manga ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Fetch' implies a read-only operation, but with no annotations, the description carries the responsibility to disclose behavioral traits such as permissions, rate limits, response size, or error conditions. It mentions optional field selection but offers no further context about API behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core function ('Fetch details for one manga') and the main optional capability ('optionally selecting MAL response fields'). No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description adequately states the primary function and field-selection capability. However, it does not explain what 'details' includes, mention that manga_id is required, or differentiate from get_manga. It relies on the schema for parameter-level details and lacks richer contextual guidance, though it is not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (manga_id and fields). The tool description adds context about 'optionally selecting MAL response fields,' which clarifies the purpose of the fields parameter, but it does not elaborate on valid field values or how to use them. The manga_id parameter is self-explanatory and not enhanced by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches details for one manga, using the specific verb 'Fetch' and the resource 'details for one manga.' It distinguishes from list/ranking siblings by specifying a single manga, but does not explicitly contrast with get_manga, which may also fetch a single manga.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need details for a specific manga rather than a list or ranking. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools like get_manga or get_manga_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a manga list for a MAL user.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| status | Yes | ||
| username | Yes | MyAnimeList username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. 'Fetch' indicates a read-only operation, but it does not disclose potential issues such as private lists, rate limits, or pagination behavior. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately sized for a minimal tool description, earning a 5 for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain the required status filter, pagination options, or return value structure, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% with descriptions for limit, offset, and username. The description adds no parameter semantics beyond the schema, and status/sort lack explicit descriptions. Baseline applies since the schema covers the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a manga list for a MAL user' – a specific verb and resource. It distinguishes from sibling tools like get_manga or get_anime_list by indicating a manga-specific user list, though it does not explicitly contrast with get_anime_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring a valid username or that status is a required filter, nor does it refer users to sibling tools for other list types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch manga rankings using MAL's ranking_type query parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| ranking_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the query parameter, without stating whether the operation is read-only, how results are ordered, what the response shape is, or any side effects. For a ranking endpoint, critical behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's core purpose. It is front-loaded and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no annotations, no output schema), the description is incomplete. It does not mention pagination behavior, default ranking order, or the meaning of ranking types, leaving the agent without enough context to set expectations or handle results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers limit and offset with descriptions, but ranking_type is an enum without explanation. The description mentions 'ranking_type' but does not elaborate on its values or how it affects results. Since schema coverage is 67%, the description partially compensates but still leaves ranking_type semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('manga rankings'), which is specific and distinguishes it from sibling tools like get_anime_ranking or get_manga_list. The name and description align without needing further clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching ranking data, but it does not explicitly contrast with alternatives like get_manga_list or explain when not to use it. There is no mention of prerequisites or exclusions, landing at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch anime released in a specific MAL season and year.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| year | Yes | Season year | |
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| season | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic fetch action. It does not disclose behavioral details such as sorting, pagination, or returned data format. However, as a read-only operation, the verb 'Fetch' conveys the action clearly without misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that delivers the core purpose without any unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description provides only the primary purpose. It omits any mention of pagination, sorting options, or the response structure, but the schema covers some parameter details. The description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters with descriptions (year, limit, offset), and the description mentions 'season and year' but adds little beyond what is already in the schema. It does not add meaning to sort, limit, or offset parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Fetch'), resource ('anime'), and scope ('released in a specific MAL season and year'). It effectively distinguishes itself from sibling tools like get_anime_list or get_anime_ranking by focusing on seasonal anime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to fetch anime by season and year. It implies the specific use case and distinguishes it from more general list/ranking tools, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch anime suggestions for the authenticated MAL user.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add the important context that the tool operates for the 'authenticated MAL user', implying OAuth requirements. However, it does not disclose other behaviors such as rate limits, error handling, or whether the suggestions are deterministic. This is a minimal but not misleading disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It immediately states the core function without any filler, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two pagination parameters and no output schema, the description is adequate but leaves room for improvement. It does not explain the return format, how suggestions are generated, or any authentication failure behavior. The lack of an output schema and the vague term 'suggestions' mean the description could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters (limit and offset) with clear explanations of their roles. The tool description adds no extra meaning about how these params affect the suggestions, but since the schema is complete, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('anime suggestions'), and the target ('authenticated MAL user'). This distinguishes it from sibling tools like get_anime_ranking and get_seasonal_anime, making the purpose immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites beyond authentication, or scenarios where another tool would be more appropriate. The sibling names hint at different tools, but the description itself offers no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the authenticated MAL user's profile.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action and resource. It does not mention the optional 'fields' parameter behavior (e.g., that 'anime_statistics' includes anime stats), nor any details about the profile contents or potential errors. This is insufficient for confident invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded, with no unnecessary words. It is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain the return format or parameter effects; it does not. The single parameter is undocumented, and the description is too brief to be considered complete for a user-profile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single optional 'fields' parameter with a null default and an 'anime_statistics' option, but the description does not mention this parameter at all. Since schema description coverage is 0%, the description fails to compensate by explaining the parameter's purpose or accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and specifies the resource as 'authenticated MAL user's profile', which clearly distinguishes from sibling tools that operate on anime/manga lists. There is no other user-profile tool among siblings, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions. It does not mention authentication prerequisites or use cases beyond the basic fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an anime in the authenticated user's MAL list.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| score | No | Score from 0 to 10 | |
| status | No | ||
| anime_id | Yes | MyAnimeList anime ID | |
| comments | No | ||
| priority | No | ||
| is_rewatching | No | ||
| rewatch_value | No | ||
| num_times_rewatched | No | ||
| num_watched_episodes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'authenticated user's' (implying auth), but does not disclose partial-update behavior, whether new entries can be created, error handling, or idempotency. For a mutation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. While it is terse and could include more detail, it is appropriately concise for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters (most undocumented), no output schema, and no annotations, the one-sentence description is inadequate for an agent to safely invoke the tool. It lacks behavior details, parameter meanings, and update semantics, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (score and anime_id have descriptions). The description refers to 'fields' generically without enumerating the updatable parameters or explaining enum values, numeric ranges, or semantics like is_rewatching vs rewatch_value. It fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update'), the resource ('anime in the authenticated user's MAL list'), and scope. It distinguishes itself from siblings like delete_myanimelist_item and update_mymangalist, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing list entries via the authenticated user's context, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like 'the anime must already be in the list.' No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on a manga in the authenticated user's MAL list.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| score | No | Score from 0 to 10 | |
| status | No | ||
| comments | No | ||
| manga_id | Yes | MyAnimeList manga ID | |
| priority | No | ||
| is_rereading | No | ||
| reread_value | No | ||
| num_times_reread | No | ||
| num_volumes_read | No | ||
| num_chapters_read | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation targets the authenticated user's MAL list, implying authentication is required, but it does not mention reversibility, error behavior, or that existing values may be overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and the target, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters and no output schema, yet the description provides no information about return values, error conditions, or which fields are commonly updated together. This is insufficient for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, and the description adds no parameter-specific information. It merely says 'Update fields' without elaborating on which fields or any parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Update') and resource ('manga in the authenticated user's MAL list'), and the name distinguishes it from sibling tools like update_myanimelist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating the user's manga list but provides no explicit guidance on when to use this tool versus alternatives such as update_myanimelist for anime or delete_mymangalist_item for deletions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0delete_myanimelist_itemdelete_mymangalist_itemget_animeget_anime_detailsget_anime_listget_anime_rankingget_mangaget_manga_detailsget_manga_listget_manga_rankingget_seasonal_animeget_suggested_animeget_user_profileupdate_myanimelistupdate_mymangalistScored across 15 tools
Each tool has a distinct purpose: search vs details vs rankings vs seasonal vs user lists vs suggestions, and clear update/delete operations for user lists. No two tools appear to do the same thing.
Most tools follow a 'get_<resource>_<modifier>' pattern, but a few deviate (e.g., get_seasonal_anime, get_suggested_anime) and the delete/update tools use 'myanimelist'/'mymangalist' as one word, which is inconsistent with the underscore style elsewhere. Still, the verb-noun convention is consistent and predictable.
15 tools is appropriate for a server covering both anime and manga, including search, details, rankings, seasonal, user lists, suggestions, profile, and list management. Each tool serves a clear purpose without excessive overlap.
The set covers the main workflows: searching, retrieving details, rankings, seasonal anime, user lists, suggestions, profile, and updating/deleting user list entries. The only notable gap is the lack of an explicit 'add to list' operation, though update may implicitly cover it.
Access and interact with anime and manga data seamlessly. Retrieve detailed information about your…
AniList MCP — wraps AniList GraphQL API (free, no auth)
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Jikan MCP — wraps the Jikan v4 API (anime/manga data, free, no auth)