MyAnimeList MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes (anime vs manga, search vs details vs rankings). However, the delete tools have identical descriptions erroneously referencing anime only, and the similarity between get_anime (search) and get_anime_details (by ID) could cause some confusion.
Naming Consistency3/5
Tools generally follow a verb_noun pattern, but there are inconsistencies: 'delete_myanimelist_item' vs 'delete_mymangalist_item' (mixed prefix casing), and 'update_myanimelist' vs 'update_mymangalist' (inconsistent 'my' inclusion). The 'get_anime' vs 'get_anime_details' naming is fine.
Tool Count5/5
15 tools is well-scoped for a MyAnimeList server, covering search, details, user lists, rankings, seasonal, suggestions, and update/delete for both anime and manga without being overwhelming.
Completeness4/5
The tool set covers most expected operations (search, details, lists, rankings, updates, deletions) for both anime and manga. Minor gaps: no explicit 'create/add' tool (though update may serve), and the delete tools' descriptions are misaligned, but overall the surface is comprehensive.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description contradicts the schema by referencing 'anime_id' instead of 'manga_id'. It does not disclose authentication requirements or effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short, but accuracy is flawed. Conciseness does not compensate for the misleading content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a contradictory description, the tool definition is severely incomplete. It does not clarify return type or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage. The description mentions 'anime_id' but the actual parameter is 'manga_id', creating confusion and failing to add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it deletes an anime, but the tool name and schema refer to manga. This is misleading and fails to accurately define the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like delete_myanimelist_item or update_mymangalist. The description does not differentiate between anime and manga.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'updates' without disclosing important behavioral traits such as authentication, idempotency, error handling (e.g., manga not in list), rate limits, or whether it's a partial or full update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an Arg block that largely duplicates the schema. While structured, it is not maximally concise; the Arg block could be omitted or shortened since the schema already provides details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description lacks essential context: no return value description, no error scenarios, no authentication requirements, and no behavioral details. It is incomplete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents parameters well. The description adds marginal value by listing possible status values and repeating schema info, but does not add new semantic context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a manga's status in the user's MyAnimeList, but it implies only 'status' when the tool can update many fields like score, volumes, etc. However, the Args list compensates, and sibling tools like update_myanimelist differentiate by resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites (e.g., authentication, manga must be in list), and no when-not-to-use conditions. The sibling tools are not mentioned or compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic fetch operation. It does not disclose whether it is read-only, mention rate limits, data freshness, or pagination behavior. Additionally, it contradicts the schema by stating default limit is 10 while schema says 100.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a docstring-style Args block, but it includes a factual error and uses Python-specific formatting that may not be ideal for all agents. It could be more structured and accurate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description should cover return format, error handling, and pagination details. It does not mention what the function returns or how to handle errors, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the ranking_type options and mentions defaults for limit and offset, but the default for limit is incorrect (description says 10, schema says 100). This error reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches manga rankings from MyAnimeList' with a specific verb and resource, and distinguishes this tool from siblings like get_manga_list or get_manga_details, which deal with individual manga or lists rather than rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_manga_list or get_manga_ranking from other sources. There are no prerequisites, limitations, or examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the action but does not specify side effects (e.g., irreversibility, need for authentication), consequences (e.g., notifications), or whether the deletion is permanent. This is insufficient for an AI agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the main action. However, the parameter line is somewhat redundant given the schema. Overall, it is efficient but could be slightly improved by removing the docstring structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool, the basic action is clear. However, it lacks critical context about authentication and the prerequisite that the anime must exist in the user's list. Given the sibling tools (e.g., delete_mymangalist_item), the naming provides some context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema lacks parameter descriptions. The description only restates 'anime_id: The ID of the anime to delete,' which adds no meaning beyond the schema's type and requirement. No format, source, or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Deletes an anime from the authenticated user's MyAnimeList.' It specifies the verb 'delete', the resource 'anime', and the context 'authenticated user's list', distinguishing it from sibling tools like 'delete_mymangalist_item' and 'update_myanimelist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., update_myanimelist) or prerequisites (e.g., authentication, existence of the item). The description does not mention when not to use it, such as if the anime is not in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the basic read operation but omits details like rate limits, authentication, or pagination behavior beyond offset/limit. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, then a structured Args block. No fluff, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description doesn't explain return format or errors. For a search tool, missing pagination/total result info. Adequate for simple use but not fully complete given sibling complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args block explains q, limit, and offset with defaults and max (limit). This adds significant meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a list of anime based on a search query, with a specific verb and resource. It is distinct from siblings like get_anime_details (single anime) and get_anime_ranking (ranking), though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It lacks context about when not to use it or which sibling is better for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavioral traits. It only states the basic fetch operation without mentioning authentication, rate limits, or any side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with 'Args:' section, which is structured but slightly verbose. The main purpose is front-loaded, but parameter details could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basics with 5 parameters and 2 required, but lacks details on output format or how it differs from similar tools like get_anime_list. No output schema, so description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining each parameter: season enum values, year type, sort options, limit default and max, offset default. Adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches seasonal anime from MyAnimeList' with specific verb and resource. It distinguishes from sibling tools like get_anime_list or get_anime_ranking by focusing on seasonal data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching seasonal anime but does not explicitly state when to use this tool versus alternatives like get_anime or get_anime_list. No guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states it fetches suggestions without revealing side effects, authentication needs, rate limits, or return format. Basic read operation is implied, but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a single sentence for purpose followed by an Args block. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 optional params, no output schema, no annotations), the description covers the main action and parameter details. However, it lacks mention of authentication requirements and return value structure, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by thoroughly documenting both parameters: limit (default 10, max 100) and offset (default 0). This provides clear semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches suggested anime for the current user from MyAnimeList,' specifying the action (fetches), resource (suggested anime), scope (for the current user), and source (MyAnimeList). It distinguishes from sibling tools like get_anime, get_anime_ranking, and get_seasonal_anime, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 scenarios where get_suggested_anime is appropriate or when other sibling tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature, rate limits, or authentication needs. It only explains input parameters but omits any operational context beyond the obvious 'fetch' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections for each parameter. However, it is somewhat verbose, resembling a docstring. A more streamlined version could convey the same information more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the input parameters comprehensively. However, it does not explain the output format or pagination behavior beyond offset/limit, leaving some gaps in completeness for a fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by listing each parameter with valid options (ranking_type enum), defaults and maximum for limit, and offset purpose. This adds meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches anime rankings from MyAnimeList' with a specific verb and resource. It distinguishes from sibling 'get_manga_ranking' by specifying anime. Additional context on ranking types further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like 'get_seasonal_anime' or 'get_suggested_anime'. The description lacks context for selection criteria, leaving the agent to infer usage from parameter differences alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully bear the burden of behavioral disclosure. It states the tool updates the authenticated user's list, implying a write operation, but does not mention potential side effects, authorization requirements beyond 'authenticated', rate limits, or whether the update is reversible. The parameter list provides some detail but lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, followed by a structured Args list. It is appropriately sized for a tool with 10 parameters, though the Args section is repetitive of the schema. No unnecessary fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description explains what the tool does and lists all parameters, but it lacks information about return values, error handling, or behavior when optional parameters are omitted. The description is adequate for basic usage but not complete for a multi-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description largely repeats the schema parameter descriptions (e.g., 'score: The score given to the anime (0-10).') without adding new semantic value. The description does not clarify parameter interactions, default behaviors beyond schema, or usage patterns, so it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Updates) and the target resource (anime's status in MyAnimeList), with enough specificity to distinguish from sibling tools like update_mymangalist. The first sentence is a complete and unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating anime list entries but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The context of being an 'update' tool is clear, but no direct comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions pagination via limit/offset and lists parameters, but does not state that the tool is read-only, require authentication, or describe rate limits. The word 'fetches' implies a read operation, but this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear purpose sentence and then listing parameters in a structured Args block. Every sentence is informative, no redundancy, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values. However, it covers all input parameters thoroughly. The tool's role among 14 siblings is partially clarified by the word 'list', but additional context about return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining all 5 parameters: username (user identity), status (options listed), sort (options and default), limit (default and max), offset (default). This adds significant meaning beyond the schema's types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches an anime list for a user from MyAnimeList', specifying the verb and resource. However, it does not differentiate from sibling tools like get_anime or get_anime_ranking, which could cause confusion about which tool to select for list retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_anime or get_seasonal_anime. The description lacks context for tool selection and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it fetches data, mentions optional fields with defaults, and lists valid fields. Missing info on error handling, authorization (likely none), rate limits, or whether it modifies data. Adequate for a read operation but could be more exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for general description, args, and examples. A bit verbose due to full field list and multiple examples, but each part adds value. The 'Args:' header is redundant given the schema, but overall concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), description covers purpose, parameters, and usage patterns via examples. Lacks explicit mention of response structure (e.g., JSON object containing requested fields), but the field list implies the shape. Sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains both parameters: manga_id as the ID, fields as a list with default behavior (if None, includes common fields) and enumerated valid values. Adds significant meaning beyond schema types, though format of fields list (e.g., comma-separated) could be clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetches details of a manga by its ID from MyAnimeList.' Specific verb ('fetches') and resource ('details of a manga') with source mentioned, distinguishing it from sibling tools like 'get_manga' (list mangas) and 'get_anime_details' (anime resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show specific use cases (score, recommendations, genres). No explicit when-not or alternatives, but the context of fetching by ID implies it's for individual manga details, not bulk operations. Clear enough for the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It outlines parameters and their defaults but does not disclose behaviors such as authentication requirements, rate limits, or error handling. The description is adequate for a simple fetch operation but lacks deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear one-sentence purpose followed by a bullet-point list of parameters. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose and all parameters adequately. Missing some behavioral context (e.g., what happens if user not found) but is complete enough for a straightforward list-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains every parameter: username, status (with enum options), sort (with enum options), limit (with default and max), and offset (with default). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a manga list for a user from MyAnimeList, with a specific verb and resource. This distinguishes it from sibling tools like get_manga (single manga) or 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like get_anime_list or get_manga_ranking. Usage is implied by the tool name and parameters, but no exclusions or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It implies a read operation ('Fetches') but does not explicitly state it is read-only, mention rate limits, authentication requirements, or side effects. It does list valid fields and defaults, which adds some 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear sentence, parameter docs, and examples. It is front-loaded with the main purpose. However, it is slightly verbose with the full field list, which could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters and no output schema, the description covers purpose, parameters (with defaults and valid values), and examples. It does not describe the response format, which might be inferred from field names, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains both parameters: anime_id is the ID, and fields is a list of fields to include with a comprehensive list of valid values and default behavior. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetches' and the resource 'details of an anime by its ID from MyAnimeList'. It distinguishes from siblings like get_anime (which may be simpler) and get_anime_list (list vs detail) through the specificity of fetching detailed fields beyond basic info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples, default field behavior, and lists valid fields, giving clear context. However, it does not explicitly state when to use this tool versus alternatives like get_anime or get_anime_ranking, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 setting 'fields' to 'anime_statistics' includes statistics, which adds behavior. But it does not mention authentication requirements, rate limits, or any side effects, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a structured Args block. Every element adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one optional parameter and no output schema, the description is largely adequate. It covers the function and parameter, though it could briefly mention expected return data for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains the 'fields' parameter and its usage (e.g., 'Set to "anime_statistics" to include anime statistics'). This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches'), the resource ('profile of the current user'), and the source ('from MyAnimeList'). It uniquely identifies the tool's purpose relative to siblings like 'get_anime' or 'get_manga'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the current user's profile. It mentions an optional parameter ('fields') to include anime statistics, providing some guidance. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation via 'fetches', which is appropriate. However, it does not explicitly state behavioral traits like auth requirements or rate limits, but for a fetch tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by structured parameter details. Every sentence is useful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and lack of output schema, the description covers the core functionality and parameter usage. However, it could benefit from mentioning the return format or differentiating from similar sibling tools like get_manga_list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides clear explanations for all three parameters (q, limit, offset), compensating for the 0% schema description coverage. It adds meaning beyond the schema, such as default values and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a list of manga based on a search query, using specific verb and resource. It distinguishes from sibling tools like get_anime or get_manga_details by focusing on list retrieval with search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives like get_manga_list or get_manga_details. It only states functionality, leaving the choice to the agent without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![myanimelist-mcp-server MCP server](https://glama.ai/mcp/servers/nicoaguerrero/myanimelist-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/nicoaguerrero/myanimelist-mcp-server)

Score Badge

Copy to your README.md:

[![myanimelist-mcp-server MCP server](https://glama.ai/mcp/servers/nicoaguerrero/myanimelist-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/nicoaguerrero/myanimelist-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nicoaguerrero/myanimelist-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server