Provides tools to access and analyze a user's MyAnimeList data including watch list, scores, episode progress, and public anime catalog.
Click on "Install 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., "@mal-mcp analyze my anime taste"
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.
An MCP server that exposes your MyAnimeList data — watch list, scores, progress, rankings, recommendations — as tools, plus a premium MCP Apps UI that renders those results as an interactive, anime-styled interface right inside the chat. Any assistant that speaks MCP can analyze your taste, browse seasons, and edit your list; on hosts that support MCP Apps it does so through the UI below.
Python 3.12 · FastMCP 3 (stdio) · React + Vite for the UI.
Requires uv. No clone, no build, no Docker.
uvx myanimelist-mcpThe server speaks MCP over stdio: it prints nothing and waits on stdin for JSON-RPC, so
running it by hand looks like a hang — that is correct behaviour. Your MCP client is what
launches it. Add it to your client config — macOS
~/Library/Application Support/Claude/claude_desktop_config.json,
Windows %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"myanimelist": {
"command": "uvx",
"args": ["myanimelist-mcp"],
"env": {
"MAL_CLIENT_ID": "your-client-id",
"MAL_CLIENT_SECRET": "your-client-secret",
"MAL_REFRESH_TOKEN": "your-refresh-token",
"MAL_TIMEZONE": "Europe/Istanbul"
}
}
}
}Then quit and reopen the client completely. See Authentication for how to get those credentials.
spawn uvx ENOENT? Desktop clients launch servers with a minimalPATHthat usually excludes~/.local/bin. Runwhich uvxand put the absolute path in"command".
Your credentials live in that file in plaintext, and stderr from this server is persisted by some clients (e.g.
~/Library/Logs/Claude/). Considerchmod 600on the config, and revoke the MAL token if you ever share logs.
For Claude Code:
claude mcp add --env MAL_CLIENT_ID=… --env MAL_REFRESH_TOKEN=… \
--transport stdio myanimelist -- uvx myanimelist-mcpPinning a version, or installing with pip instead:
uvx --from 'myanimelist-mcp==X.Y.Z' myanimelist-mcp
pip install myanimelist-mcp # then "command": "myanimelist-mcp"
# or "command": "python", "args": ["-m", "mal_mcp"]Related MCP server: mal-mcp
Each read tool ships a ui:// app resource alongside its text summary, so hosts that support
MCP Apps render the result as a
live view. The model still receives the compact text summary; the full data travels to the
iframe as structured content. Where the host has no MCP Apps support, the tools degrade to
those text summaries and everything still works.
The detail and list views edit your MAL entries in place (status / score / progress) and navigate between titles — all through the same tools, so nothing UI-only happens behind the model's back. The theme follows the host's light/dark mode; cover art loads from MAL's CDN.
Anime
Tool | Description |
| A page of your list: title, cover, watch status, score, episode progress, genres, community mean, studios. |
| Locally computed summary: status/score/genre/media-type/decade distributions, total episodes, estimated watch time, user-vs-community score deviation, top studios. |
| Public catalog search (compact results with covers, truncated synopsis). |
| Full public detail incl. related anime, recommendations, statistics, and your own list entry if present. |
| Token-efficient raw export of the whole list (grouped by status, sorted by score) for the calling model to analyze — this tool itself performs no analysis. |
Manga
Tool | Description |
| Public manga catalog search (chapters/volumes, authors, genres). |
| Full manga detail incl. authors, serialization magazines, related works, recommendations, and your own entry if present. |
| A page of your manga list with chapter/volume progress. |
Discovery
Tool | Description |
| MAL's official rankings: all, airing, upcoming, tv, ova, movie, special, bypopularity, favorite. |
| Manga rankings: all, manga, novels, oneshots, doujin, manhwa, manhua, bypopularity, favorite. |
| Anime of one broadcast season (winter/spring/summer/fall). |
| MAL's personalized suggestions for the authenticated user. |
| Your personal weekly airing calendar: the currently-airing anime on your |
Users
Tool | Description |
| Your profile + lifetime anime statistics. MAL exposes this only for |
| Another user's public anime list (403 usually = private list or unknown user). |
| Another user's public manga list. |
Write tools — these modify your MAL list
Tool | Description |
| Update score/status/episode progress/tags — or add the anime to the list. Only provided fields change. |
| Permanently remove an anime from the list (cannot be undone). |
| Same as the anime variant, with chapter/volume progress. |
| Permanently remove a manga from the list. |
Aggregate tools (get_user_stats, analyze_taste) fetch the entire list in one paginated
pass (safety cap: 20,000 entries — beyond that a truncated/WARNING marker is included).
paging.next URLs are validated (https + api.myanimelist.net) before being followed, so
the bearer token can never be sent elsewhere. Verified MAL API facts (fields syntax,
pagination, limits, error shapes) are documented in NOTES.md.
uv sync # install Python dependencies
uv run pytest # unit tests (pure helpers, no network)
uv run myanimelist-mcp # run the server over stdio (waits on stdin for JSON-RPC)The server runs without the UI bundle (it serves a small placeholder), so a clone never needs Node. To build the real interface:
cd ui
npm ci
npm run build # emits src/mal_mcp/ui/dist/index.html (a single self-contained file)For UI development without a host, npm run dev in ui/ renders every view with fixture
data and a view switcher — the screenshots above are those views.
Released wheels always ship a freshly built bundle: .github/workflows/publish.yml builds it
before uv build and fails the release if it is missing.
The server needs a MyAnimeList access token and stores nothing on disk. Set the credentials in
the "env" block of your MCP client config, in one of two ways (this is the precedence order):
MAL_REFRESH_TOKEN (+ MAL_CLIENT_ID, MAL_CLIENT_SECRET) — recommended. The server
mints and renews access tokens itself via the OAuth refresh_token grant, in memory only.
Set up once, no monthly re-pasting.
MAL_ACCESS_TOKEN — a static token (expires ~31 days); simplest for a quick test.
Create an API app at https://myanimelist.net/apiconfig → Create ID, App Type: Web
(this is what makes MAL issue a Client Secret). Set the redirect URL to your OAuth
callback, or a localhost URL like http://localhost:8080/callback for the manual flow.
MAL uses plain PKCE only (no S256), so the code verifier and challenge are the
same string. Obtain a token once:
# 1) code verifier (43-128 chars); challenge == verifier for plain PKCE
VERIFIER=$(python3 -c "import secrets; print(secrets.token_urlsafe(64)[:100])")
# 2) open in a browser, log in, approve — you get ?code=<CODE> at your redirect URL:
# https://myanimelist.net/v1/oauth2/authorize?response_type=code&client_id=<CLIENT_ID>&code_challenge=$VERIFIER&code_challenge_method=plain&state=x&redirect_uri=<URL_ENCODED_REDIRECT_URL>
# 3) exchange the code for tokens:
curl -s https://myanimelist.net/v1/oauth2/token \
-d client_id=<CLIENT_ID> -d client_secret=<CLIENT_SECRET> \
-d grant_type=authorization_code -d code=<CODE> \
-d code_verifier=$VERIFIER -d redirect_uri=<REDIRECT_URL>
# → {"token_type":"Bearer","expires_in":2678400,"access_token":"...","refresh_token":"..."}Keep the refresh_token for MAL_REFRESH_TOKEN (option 1), or the access_token for
MAL_ACCESS_TOKEN (option 2).
Variable | Default | Purpose |
| (unset) | Enables self-renewing tokens via the |
| (unset) | MAL app Client ID, for the refresh grant. |
| (unset) | MAL app Client Secret — required for "Web"-type apps. |
| (unset) | Static fallback token (expires ~31 days). |
| (unset → JST) | Default IANA timezone for |
src/mal_mcp/
├── server.py # FastMCP app, token helper, 20 tools, stats/format/summary helpers
├── mal_client.py # MAL API wrapper: fields, pagination (paging.next), retries, error mapping
├── token_manager.py# self-renewing OAuth refresh_token grant (in-memory)
├── __main__.py # `python -m mal_mcp`
└── ui/ # MCP Apps layer: ui:// resource + meta/ToolResult helpers
└── dist/ # built single-file HTML bundle (gitignored; built by CI for releases)
ui/ # Vite + React + TypeScript app (motion animations, 6 views)
tests/ # offline unit tests (pure helpers, token manager, UI contract)
NOTES.md # verified MAL API / FastMCP factsThe PyPI distribution is myanimelist-mcp; the import package is mal_mcp.
Return the user's entire anime list in a compact, token-efficient text format.
This tool performs NO analysis - it exports the raw data (grouped by watch status, sorted by the user's score) so the calling model can analyze taste, spot patterns, and craft recommendations. Line format: my_score|title|year|type|watched/total_eps| genres|mal_mean ('-' = not scored / unknown). Lists longer than the 20,000-entry fetch cap are exported partially, with a leading WARNING line.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing the no-analysis policy, format, grouping, sorting, and the fetch cap with warning line, which goes beyond annotations.
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 three sentences plus a format line, all front-loaded with purpose and key details. Every sentence adds value with no 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?
Given no parameters and good annotations, the description covers output format, sorting, grouping, and fetch cap warning. It lacks explicit mention of whether the list includes all watch statuses or just completed, but the context is sufficient.
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?
No parameters exist (schema coverage 100%), so the description focuses on output format and behavior. It adds significant meaning about the expected output, which is crucial for agent usage.
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 returns the user's entire anime list in a compact text format, explicitly says it performs NO analysis, and the title 'raw data export' distinguishes it from siblings like search_anime and get_my_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?
The description says to use this when you need raw data for analysis and clarifies it does not perform analysis. It implies alternatives are analysis tools or model post-processing, but lacks explicit when-not-to-use guidance for specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PERMANENTLY remove an anime from the authenticated user's list.
This deletes the entry's score, progress, dates, and tags on MAL - it cannot be undone. MAL treats the delete as idempotent in practice (removing an entry that is already absent still succeeds); a 404 for an unknown id returns a clear message.
| Name | Required | Description | Default |
|---|---|---|---|
| anime_id | Yes | MAL anime id |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations: clarifies permanent deletion, cannot be undone, idempotent behavior, and 404 handling. No contradiction with annotations.
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?
Two sentences, front-loaded with key action. No wasted 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?
Given annotations and output schema, description is complete: explains permanence, idempotency, and error behavior.
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%; description does not add new info about the single parameter. Baseline 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 the action (PERMANENTLY remove), the resource (anime from user's list), and scope (authenticated user). It distinguishes from siblings like update or delete manga entry.
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?
Description mentions permanence and idempotent behavior, but does not explicitly state when to use versus alternatives or prerequisites (e.g., must be authenticated, entry must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PERMANENTLY remove a manga from the authenticated user's list.
This deletes the entry's score, progress, dates, and tags on MAL - it cannot be undone. MAL treats the delete as idempotent in practice (removing an entry that is already absent still succeeds); a 404 for an unknown id returns a clear message.
| Name | Required | Description | Default |
|---|---|---|---|
| manga_id | Yes | MAL manga id |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the destructive effects (deletes score, progress, dates, tags) and confirms permanence, which goes beyond the annotations (destructiveHint: true). It also discloses idempotent behavior and error handling (404 for unknown id), adding valuable 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 concise, with only two sentences. The first sentence front-loads the main action, and the second provides critical behavioral details. No redundant or extraneous 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 simple delete operation with one parameter and an output schema, the description covers the key aspects: what is removed, permanence, idempotency, and error behavior. It could be slightly improved by explicitly mentioning authentication requirement, but the tool name and context imply 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?
With 100% schema coverage, the schema already describes 'manga_id' as 'MAL manga id'. The description does not add further semantic meaning to the parameter beyond the context of the delete action, so it meets the baseline.
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 ('PERMANENTLY remove a manga') and the resource ('from the authenticated user's list'). It directly distinguishes from sibling tools like 'update_my_manga_entry' (update vs delete) and 'delete_my_anime_entry' (manga vs anime), leaving no ambiguity.
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 removing a manga entry and warns about permanence. It does not explicitly mention when not to use it or direct to a sibling tool like 'delete_my_anime_entry', but the context of siblings and clear action provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full public details for one anime by its MAL id.
Returns title(s), synopsis, community stats (mean, rank, popularity, list/scoring user counts, per-status statistics), airing info, source, rating, genres, studios, related_anime, and up to 10 community recommendations. If the anime is on the authenticated user's list, my_list_status (their status/score/progress) is included.
| Name | Required | Description | Default |
|---|---|---|---|
| anime_id | Yes | MAL anime id, e.g. from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world. The description adds detailed return fields (title, synopsis, stats, etc.) and conditional inclusion of my_list_status, which is valuable behavioral context beyond annotations.
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?
Description is extremely concise: one sentence for purpose, one sentence enumerating returned content. No fluff, every sentence adds value.
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 no output schema, the description fully enumerates returned fields and notes conditional data. It covers all expected aspects for a simple detail-fetch tool, with no gaps.
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 for anime_id is 100%, and the description provides no additional meaning beyond the schema's own description. Baseline of 3 is appropriate as no extra semantics are needed.
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 full public details for one anime by its MAL id, using specific verb 'Fetch' and resource 'anime'. It distinguishes itself from siblings like search_anime (returns list) and get_anime_ranking (ranking 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?
The description implies usage: when you have a specific MAL id and want detailed info. It indirectly guides usage by mentioning the required parameter, but lacks explicit when-not or alternative tools mention. However, context signals and sibling names fill the gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch MAL's official anime rankings.
ranking_type: all (top by score), airing, upcoming, tv, ova, movie, special, bypopularity, favorite. Returns a compact text table plus structured content {"ranking_type", "total_returned", "offset", "has_more", "entries"}; each entry: rank, previous_rank, id, title, picture, year, media_type, mean, num_list_users, num_episodes, airing_status, genres.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| ranking_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (readOnlyHint, openWorldHint) by detailing the return format (text table + structured content) and pagination behavior (offset, has_more). It does not contradict annotations. A 5 would require even more depth, such as rate limits or caching, but it is already strong.
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 front-loaded with the main purpose and then provides details on ranking types and return structure. It is informative without being overly verbose, though the list could be slightly streamlined. Every sentence earns 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?
Given no output schema, the description fully explains the return values and their meaning. It covers ranking types, pagination fields, and entry details. Combined with thorough annotations, this makes the tool self-contained for correct invocation.
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 adds meaning beyond the input schema by listing the ranking_type enum values and explaining that 'all' means top by score. It also describes the return structure with fields like 'total_returned' and 'has_more'. Schema description coverage is high (67%), so the baseline is 3, but the description compensates well.
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 MAL's official anime rankings' with a specific verb and resource. It lists ranking types and the return structure, making the purpose explicit. However, it does not explicitly differentiate from sibling tools like search_anime or get_anime_detail, which would raise it to 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?
The description implies usage for fetching rankings but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest siblings for other purposes. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full public details for one manga by its MAL id.
Returns title(s), synopsis, community stats (mean, rank, popularity), publication info, chapter/volume counts, genres, authors, serialization magazines, related_manga/related_anime, and up to 10 community recommendations. If the manga is on the authenticated user's list, my_list_status is included.
| Name | Required | Description | Default |
|---|---|---|---|
| manga_id | Yes | MAL manga id, e.g. from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds transparency by listing the specific data returned (title, synopsis, stats, etc.) and notes the conditional my_list_status. It does not contradict annotations and provides useful 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 three sentences, front-loaded with the purpose, then enumerating return fields efficiently. No wasted 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?
With one parameter and no output schema, the description adequately covers what the tool does and what it returns, including conditional fields. It does not discuss error handling or performance, but for a simple detail fetch, this is sufficient.
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%: manga_id is fully described in the schema. The description only repeats 'MAL id' and adds 'e.g. from search results', which adds minimal value. Baseline 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?
The description clearly states the verb 'fetch' and resource 'full public details for one manga by its MAL id', which is specific and distinct from sibling tools like search_manga or get_manga_ranking. The returned fields are listed, providing a clear purpose.
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 when you have a MAL id and want full details. It mentions the conditional inclusion of my_list_status, but does not explicitly contrast with siblings or state when not to use. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch MAL's official manga rankings.
ranking_type: all, manga, novels, oneshots, doujin, manhwa, manhua, bypopularity, favorite. Returns the same paged shape as get_anime_ranking; each entry: rank, previous_rank, id, title, picture, year, media_type, mean, num_list_users, num_chapters, publishing_status, authors, genres.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| ranking_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations by detailing the fields in each entry (rank, title, etc.) and referencing pagination via limit/offset. No contradiction with readOnlyHint/openWorldHint.
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?
Two concise sentences: first states purpose, second lists types and return shape. No filler, front-loaded with critical 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 read-only tool with no output schema, the description provides a thorough list of entry fields, ranking types, and references pagination. Combined with annotations, it is fully 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?
Schema coverage is 67% with descriptions for limit and offset, but ranking_type only has enum values. The description compensates by listing all ranking types and detailing the return shape, adding meaning beyond the 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 explicitly states 'Fetch MAL's official manga rankings', using a specific verb and resource. It lists ranking types and notes the return shape is identical to get_anime_ranking, distinguishing it from that sibling tool.
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 clearly indicates it is for manga rankings and provides the available ranking_type options. While it does not explicitly state when not to use it, the context is sufficiently clear given the sibling tools like get_anime_ranking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page of the authenticated user's MyAnimeList anime list.
Results are paged to keep responses bounded: use limit/offset (and has_more in
the response) to fetch further pages. For the complete list in one compact blob use
analyze_taste; for aggregates use get_user_stats.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | MAL server-side ordering: list_score (desc), list_updated_at (desc), anime_title (asc), anime_start_date (desc). Omit for MAL's default order. | |
| limit | No | Maximum entries to return in this call | |
| offset | No | Entries to skip; increase to page through large lists | |
| status_filter | No | Only return entries with this watch status (watching, completed, on_hold, dropped, plan_to_watch). Omit for the full list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=true. Description adds pagination behavior (bounded pages, has_more in response) without contradicting annotations. Lacks detail on auth requirements but implied by 'authenticated user'.
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?
Two sentences, front-loaded with purpose. Every sentence adds value: first defines action, second explains paging and alternatives. No waste.
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 4 parameters, no output schema, and siblings, description covers paging and alternatives. Could mention response fields, but not essential. Adequately complete for a simple list 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?
Input schema has 100% description coverage, covering sort, limit, offset, status_filter. Description only reinforces limit/offset for paging, adding little beyond schema. Baseline 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 'Fetch a page of the authenticated user's MyAnimeList anime list', specifying verb (fetch), resource (anime list), and scope (paged). It distinguishes from siblings like analyze_taste and get_user_stats.
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?
Explicitly explains paging mechanism with limit/offset and has_more, and provides alternatives: analyze_taste for complete list, get_user_stats for aggregates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page of the authenticated user's MyAnimeList manga list.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | list_score (desc), list_updated_at (desc), manga_title (asc), manga_start_date (desc). Omit for MAL's default order. | |
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| status_filter | No | reading, completed, on_hold, dropped, plan_to_read. Omit for all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, but the description adds no behavioral details beyond the schema (e.g., pagination behavior, ordering defaults). No mention of authentication requirements or response format.
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 sentence that directly states the tool's purpose. It is concise and front-loaded, earning its place without fluff.
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 four parameters and no output schema, the description is too minimal. It does not explain the return format, pagination details, or that authentication is required, leaving significant gaps for the agent.
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 does not add any parameter meaning beyond what the schema already provides (e.g., it does not explain sort order direction or filter usage in context).
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 a page' and the resource 'the authenticated user's MyAnimeList manga list'. It is specific and distinct from search tools, though it does not explicitly differentiate from the sibling 'get_user_manga_list' which may serve a similar purpose.
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 guidelines are provided about when to use this tool versus alternatives like 'get_user_manga_list' or 'search_manga'. The agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the authenticated user's MAL profile and lifetime anime statistics.
Returns id, name, picture, birthday, location, joined_at, time_zone, is_supporter, and anime_statistics (items/days per watch status, total episodes, rewatches, mean score). MAL only exposes this endpoint for the token's own account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds rich detail about the returned fields (id, name, picture, birthday, location, joined_at, time_zone, is_supporter, anime_statistics). No contradictions.
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 two sentences, the first stating the purpose and the second detailing the fields. Every sentence is necessary and information-dense, with front-loaded main action.
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 no parameters, simple return values, and annotations covering safety and openness, the description is complete. It lists all key return fields, providing sufficient context for the agent.
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 tool has zero parameters, and schema coverage is 100%. According to guidelines, baseline is 4, and the description does not need to add parameter info beyond what's already clear.
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 it fetches the authenticated user's MAL profile and lifetime anime statistics, listing specific fields. It distinguishes itself from siblings like 'get_user_stats' by focusing on the token's own account.
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 explicitly states that MAL only exposes this endpoint for the token's own account, implying it should not be used for other users. This provides clear context for when to use the tool, though it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the anime that aired in one broadcast season (winter/spring/summer/fall).
Seasons: winter = Jan-Mar, spring = Apr-Jun, summer = Jul-Sep, fall = Oct-Dec. sort: anime_score (desc) or anime_num_list_users (desc). Returns a compact text table plus structured content {"year", "season", "total_returned", "offset", "has_more", "entries"} with compact anime entries (including picture).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | anime_score | |
| year | Yes | Broadcast year | |
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| season | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by detailing the return format (compact text table plus structured content with fields like year, season, total_returned, offset, has_more, entries including picture). It also explains sort behavior and season definitions, going beyond annotations.
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 consists of two concise sentences. The first states the core purpose, and the second adds essential details on seasons, sorting, and return structure. Every sentence provides actionable information without 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?
Given 5 parameters and no output schema, the description sufficiently explains the output structure and paging. It covers typical use cases but omits edge case behavior (e.g., invalid year). With annotations providing safety context, the description is complete enough for effective tool use.
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 60% (3 of 5 params have descriptions). The description adds meaning beyond the schema: it explains season enum values with month ranges (winter=Jan-Mar, spring=Apr-Jun, etc.) and clarifies sort values (anime_score desc or anime_num_list_users desc). This compensates for the undocumented params.
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 that aired in a specific broadcast season, with the verb 'fetch' and resource 'seasonal anime'. It distinguishes from siblings like search_anime and get_anime_ranking by specifying season-based filtering.
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 explains when to use the tool (to get anime by season) but does not provide explicit guidance on when not to use it or alternatives. Sibling tool names imply differentiation, but the description lacks direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch MyAnimeList's personalized anime suggestions for the authenticated user.
These are MAL's own recommendations based on the user's list (empty for accounts without watch history). Returns a compact text table plus structured content {"total_returned", "offset", "has_more", "results"} with the same compact shape as search_anime.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum suggestions to return | |
| offset | No | Entries to skip for paging |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that suggestions are based on the user's list and can be empty, and describes the return shape. No contradictions with annotations.
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?
Two sentences, front-loaded with purpose, no wasted 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?
For a simple read-only tool with good annotations and full schema coverage, the description covers purpose, behavior, and return format, making it 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?
Schema descriptions cover both parameters (limit, offset) with default and bounds. The description does not add further parameter details; with 100% schema coverage, baseline 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?
The description clearly states the verb 'Fetch' and the resource 'personalized anime suggestions for the authenticated user', distinguishing it from siblings like search_anime or get_my_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?
The description explains when to use the tool (personalized suggestions) and notes that results are empty for accounts without watch history, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page of ANOTHER MAL user's anime list (works only for public lists).
Same paged shape as get_my_anime_list, plus "user_name" echoed in the response. A 403 usually means the user's list is private or the username does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| user_name | Yes | MAL username (public list) | |
| status_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the agent knows it's read-only. The description adds critical context: the tool only works on public lists and a 403 indicates private/nonexistent user. This goes beyond the structural annotations.
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?
Two sentences, no filler. Every word is functional: states purpose, access condition, shape comparison, and error hint. 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?
For a list retrieval tool with 5 parameters, no output schema, the description covers purpose, access limitation, error case, and shape. It does not explain return structure but references the sibling tool, which is acceptable.
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%, so baseline is 3. The description mentions the paged shape is same as get_my_anime_list, which helps understand pagination but does not directly detail parameter semantics beyond what's in the schema's descriptions.
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 it fetches a page of another user's anime list, specifies 'works only for public lists,' and distinguishes from get_my_anime_list by noting it's for another user. The verb 'Fetch' plus resource 'another MAL user's anime list' is specific and 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 implicitly indicates when to use it to get another user's list and gives a practical hint about 403 errors. It compares to get_my_anime_list for shape but does not explicitly state when not to use or mention alternatives. Still, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page of ANOTHER MAL user's manga list (works only for public lists).
Same paged shape as get_my_manga_list, plus "user_name" echoed in the response. A 403 usually means the user's list is private or the username does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | Maximum entries to return | |
| offset | No | Entries to skip for paging | |
| user_name | Yes | MAL username (public list) | |
| status_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=true. The description adds useful behavioral info: same paged shape as 'get_my_manga_list', plus 'user_name' echoed in response, and error conditions. No contradictions with annotations.
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?
Three sentences, each adding value. The first sentence states the core purpose, the second explains shape similarity, and the third covers error handling. No fluff, front-loaded with key 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?
The tool has 5 parameters, no output schema, and moderate schema coverage. The description covers purpose, public list constraint, shape similarity, and error handling. It could mention pagination limits or return structure, but given annotations and siblings, it is sufficiently complete for an AI agent.
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 60%, meaning 3 of 5 parameters have descriptions in the schema. The description does not add new semantic details for parameters beyond noting shape similarity to another tool. With moderate schema coverage, the description provides minimal additional value for parameters, so a baseline 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?
The description clearly states the tool fetches 'a page of ANOTHER MAL user's manga list' and specifies it only works for public lists. The verb 'fetch' and resource 'another user's manga list' are specific, and it distinguishes from sibling tools like 'get_my_manga_list' (own list) and 'search_manga' (search).
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 context that the tool works only for public lists and mentions a common error (403) meaning the list is private or username doesn't exist. It implicitly suggests using this tool over 'get_my_manga_list' when accessing another user's list, though explicit alternatives are not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute summary statistics over the authenticated user's entire anime list.
Fetches the full list in one paginated pass and aggregates locally (no extra MAL calls).
Returns a text digest plus structured content with: total_entries; status_distribution; scores (count/mean/median/1-10 histogram); episodes (total watched + estimated watch hours/days, using each show's average episode duration, ~24 min fallback); top_genres (top 15 with count and avg user score); media_type_distribution; release_decades; community_comparison (avg difference between the user's scores and MAL community means); top_studios (top 10). If the list exceeds the 20,000-entry fetch cap, "truncated": true and a warning are included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds rich behavioral details: paginated fetch, local aggregation, specific output fields including truncation warning. This exceeds mere annotations.
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 paragraph that is well-organized with clear sections: main purpose, process, output fields, and edge case. It is informative but could be slightly more concise by removing some redundancy (e.g., listing all fields twice in text).
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 no output schema and no parameters, the description must fully describe the return value. It does so comprehensively, listing all structured fields and the truncation behavior. The annotations (read-only, open-world) complement the description.
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?
There are no parameters (input schema empty), so schema coverage is 100% vacuously. Per guidelines, baseline for 0 params is 4, and the description fully explains what the tool does without needing parameters. It adds thorough output semantics.
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 'compute' and the resource 'summary statistics over the authenticated user's entire anime list.' This distinguishes it from sibling tools like get_my_anime_list (which fetches raw data) and analyze_taste (likely different analysis).
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 explains the process (one paginated pass, local aggregation) and implies it is the comprehensive stats tool. While it does not explicitly say when to use vs alternatives, the context signals and sibling names make it clear. Slightly lacking explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your personal weekly airing calendar: which anime on your 'watching' list broadcast on each day of the week.
Fetches your watching list, keeps only currently-airing shows, and groups them by
broadcast day. Times are shown in the timezone argument if given, else the
MAL_TIMEZONE env var, else MAL's native JST. When a timezone applies, both the time
and the weekday are converted (a late-night JST slot can fall on a different local
day). Shows MAL has no broadcast slot for go in an "unscheduled" group.
Returns a per-day text digest plus structured content {"timezone", "today", "total", "days": [{"day", "entries": [...]}]}; each entry has id, title, picture, media_type, my_score, episodes_watched, total_episodes, broadcast_time.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA timezone name (e.g. 'Europe/Istanbul', 'America/New_York'). Overrides the MAL_TIMEZONE env var; omit both to show MAL's native JST times. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides detailed behavioral information beyond annotations: it explains timezone conversion logic (converts both time and weekday), grouping of unscheduled shows, and the return format (text digest plus structured content). Annotations (readOnlyHint, openWorldHint) are consistent with the read-only fetching behavior described.
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 concise (5 sentences) and well-structured: it starts with a high-level purpose, then details behavior, and ends with return format. Every sentence adds value without 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?
The description covers the main functionality, return format, and parameter details. However, it could mention prerequisites (e.g., user must have a watching list) or edge cases (e.g., empty schedule). Still, it is fairly complete given the tool's simplicity.
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% with one parameter. The description adds significant context beyond the schema: it explains that the timezone overrides an environment variable and that both time and weekday are converted when a timezone is supplied, enhancing the parameter's 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 returns a personal weekly airing calendar for anime on the user's watching list, grouped by broadcast day. The verb 'get' and resource 'weekly schedule' are explicit, and it is distinct from siblings like get_my_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?
The description explains when to use the tool (to get a schedule view of currently-airing anime from the watching list) and implies usage context with timezone handling. However, it does not explicitly state when not to use it or compare to alternatives like get_my_anime_list for raw list access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MyAnimeList's public anime catalog by title.
Returns a compact text table (id|title|year|type|mean|eps|genres) plus structured content {"count": int, "results": [...]} where each result has: id, title, picture, year, media_type, airing_status, mean (community score), num_episodes, genres, and a synopsis truncated to 300 characters. Use get_anime_detail for full information.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| query | Yes | Title to search for (MAL needs ~3+ characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing the return format (text table and structured content), including truncation of synopsis to 300 characters, and noting the query character requirement. No contradictions with annotations.
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 concise with three sentences: purpose, return format, and guidance to a sibling tool. Every sentence adds value and the purpose is front-loaded, making it immediately clear.
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 simplicity (2 parameters, no output schema), the description covers the return structure, truncation, and sibling tool linkage. It is missing details on pagination or error handling, but overall is sufficiently complete 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 100%, so the schema itself documents both parameters. The description adds minor context by noting the 'query' parameter is a title search and references the character requirement (same as schema description). This provides slight added value beyond the 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 'Search MyAnimeList's public anime catalog by title,' using a specific verb and resource. It distinguishes itself from siblings by referencing get_anime_detail for full information, 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 provides clear context on when to use this tool (searching anime by title) and directs users to get_anime_detail for full information. However, it does not explicitly exclude search_manga for manga searches, though the tool name implies anime-only scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MyAnimeList's public manga catalog by title.
Returns a compact text table (id|title|year|type|mean|chapters|genres) plus structured content {"count": int, "results": [...]} where each result has: id, title, picture, year, media_type (manga/novel/one_shot/...), publishing_status, mean (community score), num_chapters/num_volumes (0 = unknown/ongoing), genres, authors, and a synopsis truncated to 300 characters. Use get_manga_detail for full information.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| query | Yes | Title to search for (MAL needs ~3+ characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Exceeds annotations by detailing output format: compact text table and structured content with fields listed. Notes that num_chapters/volumes = 0 indicates unknown/ongoing, and synopsis truncated to 300 characters. No contradiction with readOnlyHint or openWorldHint.
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?
Three sentences: first states purpose, second describes output, third directs to sibling. Every sentence adds value. Concise and well-structured.
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 no output schema, the description fully explains the return format, including both text table and structured data with all key fields. Provides completeness for a search tool by covering response shape and special values.
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. Description adds value by explaining the query parameter expects a title and notes the '~3+ characters' requirement. The limit parameter is implicitly mentioned via default, but not elaborated beyond 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?
Clearly states the verb 'search' and resource 'MyAnimeList's public manga catalog by title'. Distinguishes from sibling 'search_anime' and mentions alternative 'get_manga_detail' for full info.
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?
Explicitly states when to use: search by title. Provides a prerequisite that 'MAL needs ~3+ characters' for the query parameter. Contrasts with 'get_manga_detail' for full information, guiding the agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the authenticated user's list entry for an anime (or ADD it to the list).
Only the provided fields are changed; at least one is required. If the anime is not on the user's list yet, MAL creates the entry (e.g. pass status="plan_to_watch" to add something). Returns the updated my_list_status.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Replaces the entry's tag list | |
| score | No | 0 removes the score | |
| status | No | ||
| anime_id | Yes | MAL anime id | |
| comments | No | ||
| priority | No | ||
| is_rewatching | No | ||
| rewatch_value | No | ||
| num_times_rewatched | No | ||
| num_watched_episodes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and description confirms it modifies the list and can add entries. It also states the return type ('Returns the updated my_list_status'). However, it does not elaborate on potential side effects beyond the mutation, but overall adds value beyond annotations.
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?
Description is two clear sentences, front-loaded with the core action and extending with usage notes. 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?
Output schema exists so return values are documented. However, with 10 parameters and many siblings, the description could be more complete by covering error conditions or authentication requirements. The key adding behavior is explained, but gaps remain in parameter semantics.
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?
Input schema has 10 parameters with only 30% description coverage. Description does not explain the purpose or format of the remaining 7 parameters (e.g., comments, priority, num_watched_episodes). The vague statement 'Only the provided fields are changed' does not compensate for the lack of individual parameter guidance.
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 states 'Update the authenticated user's list entry for an anime (or ADD it to the list)', clearly specifying verb and resource. It distinguishes from siblings like delete_my_anime_entry and update_my_manga_entry by focusing on updating/adding an entry.
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?
Description explains that only provided fields are changed, at least one is required, and that if the anime is not on the list, MAL creates the entry with an example (pass status='plan_to_watch'). This provides clear usage context, though it does not explicitly mention when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the authenticated user's list entry for a manga (or ADD it to the list).
Only the provided fields are changed; at least one is required. If the manga is not on the user's list yet, MAL creates the entry (e.g. pass status="plan_to_read" to add something). Returns the updated my_list_status.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Replaces the entry's tag list | |
| score | No | 0 removes the score | |
| status | No | ||
| comments | No | ||
| manga_id | Yes | MAL manga id | |
| priority | No | ||
| is_rereading | No | ||
| reread_value | No | ||
| num_times_reread | No | ||
| num_volumes_read | No | ||
| num_chapters_read | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool can create entries if absent, only changes provided fields, and returns updated status. This adds context beyond annotations (idempotent, destructive). It does not detail destructive behavior (e.g., clearing fields by passing null), but annotations already flag destructiveHint=true. Return value is mentioned, which aligns with output schema presence.
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 two sentences, front-loaded with the primary purpose. Every sentence contributes essential information: purpose and usage rules. No redundancy or filler. Ideal length for quick comprehension.
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 11 parameters and low schema coverage, the description is insufficient. It does not elaborate on the majority of parameters or their interactions. While output schema exists, the description should provide more context for correct parameter usage, especially for less obvious fields like 'is_rereading' or 'priority'.
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?
With schema coverage at 27%, the description should compensate by explaining parameters. It only mentions 'status' as an example for adding entries. Other 10 parameters (tags, score, comments, etc.) lack explanation of their effects or valid values beyond schema. The description adds minimal semantic value to 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 tool updates or adds a manga entry to the user's list. It distinguishes from siblings like 'update_my_anime_entry' and 'delete_my_manga_entry' by focusing on manga list mutation. The verb 'update' and explanation of creating if missing make 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 explains that only provided fields change and at least one field is required, which is a usage rule. It also gives an example for adding a manga (pass status='plan_to_read'). However, it does not explicitly compare to sibling tools like 'delete_my_manga_entry' or 'get_my_manga_list', nor does it specify when to use update vs. other mutations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation (search, get detail, list user list, update entry, delete entry, etc.) with clear boundaries. Overlap between get_my_anime_list and analyze_taste is addressed by descriptions, with analyze_taste exporting raw data for model analysis.
All tools follow a consistent verb_noun pattern (e.g., search_anime, get_manga_detail, update_my_anime_entry). The few variations like get_my_anime_list vs get_user_anime_list are justified by different targets.
20 tools is well-scoped for a comprehensive MyAnimeList client, covering catalog queries, user list management, rankings, seasonal, suggestions, schedule, and profile. No excessive or missing tools for the domain.
The tool set covers virtually all major MAL operations: search/get detail for anime and manga, full CRUD on user lists, rankings, seasonal anime, suggestions, weekly schedule, user profiles, and other users' lists. No significant gaps for personal anime/manga tracking.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Run your website's AI support agent from Claude, Cursor or any MCP client. Manage the knowledge base, edit agent instructions, read conversations and leads, reply live to visitors, and check plan usage. 54 tools, OAuth sign-in, no API key. Free with every Asyntai account: https://asyntai.com/documentation/mcp/
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/UmutKDev/myanimelist-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
