MyAnimeList MCP Server

by MorpKnight

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a distinct purpose: search vs details vs rankings vs seasonal vs user lists vs suggestions, and clear update/delete operations for user lists. No two tools appear to do the same thing.
Naming Consistency4/5
Most tools follow a 'get_<resource>_<modifier>' pattern, but a few deviate (e.g., get_seasonal_anime, get_suggested_anime) and the delete/update tools use 'myanimelist'/'mymangalist' as one word, which is inconsistent with the underscore style elsewhere. Still, the verb-noun convention is consistent and predictable.
Tool Count5/5
15 tools is appropriate for a server covering both anime and manga, including search, details, rankings, seasonal, user lists, suggestions, profile, and list management. Each tool serves a clear purpose without excessive overlap.
Completeness4/5
The set covers the main workflows: searching, retrieving details, rankings, seasonal anime, user lists, suggestions, profile, and updating/deleting user list entries. The only notable gap is the lack of an explicit 'add to list' operation, though update may implicitly cover it.
Average 3.3/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It only indicates a read operation ('Fetch') but does not explain return format, pagination, permissions, rate limits, or side effects. The optional 'fields' hint is the only extra detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately short for a simple tool, though the brevity sacrifices useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and relies on the description for completeness. However, the description does not explain what 'details' are included, what fields are available, or how it differs from 'get_anime'. This makes it incomplete for an agent deciding whether and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal descriptions for both parameters ('MyAnimeList anime ID' and 'MAL response fields'). The description adds that field selection is optional but fails to explain what valid 'MAL response fields' are, leaving agents to guess. Schema coverage is only 50%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('details for one anime'), and mentions the optional 'fields' selection. However, it does not distinguish itself from the sibling tool 'get_anime', leaving potential ambiguity about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_anime' or 'get_anime_ranking'. It does not describe context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action and mentions the ranking_type query parameter, but does not disclose pagination behavior, return format, authentication requirements, or any potential side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and resource. It contains no fluff or redundant information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values, ordering, pagination, or authentication. None of these are mentioned. The description provides only a minimal overview, leaving significant gaps for an agent relying on it alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (limit and offset have descriptions), and ranking_type has an enum. The description adds minimal value by mentioning ranking_type but does not explain its possible values or how it influences results. This aligns with the baseline for moderate schema coverage where the schema handles most parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches anime rankings, which is a specific verb+resource pair. However, it does not explicitly distinguish this from sibling tools like get_manga_ranking or get_seasonal_anime, though the resource name provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of scenarios, exclusions, or contrasting sibling tools, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the search function and offers no details on pagination, result ordering, or output structure. There is no mention of side effects or limitations, leaving significant room for misjudgment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core purpose, matching the standard of high-conciseness examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and sparse annotations, the description should explain what the search returns. It does not mention result format or list properties, leaving the agent under-informed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal nuance by clarifying 'q' is a title or text query, but this is a minor enhancement over the schema's 'Search query'. It does not elaborate on limit or offset behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('MyAnimeList manga'), clearly indicating this is a search tool. It distinguishes from siblings like get_manga_details or get_manga_ranking, but doesn't explicitly contrast with get_manga_list, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention exclusions or when get_manga_list or get_anime would be more appropriate, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action and resource. It does not mention the optional 'fields' parameter behavior (e.g., that 'anime_statistics' includes anime stats), nor any details about the profile contents or potential errors. This is insufficient for confident invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded, with no unnecessary words. It is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain the return format or parameter effects; it does not. The single parameter is undocumented, and the description is too brief to be considered complete for a user-profile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single optional 'fields' parameter with a null default and an 'anime_statistics' option, but the description does not mention this parameter at all. Since schema description coverage is 0%, the description fails to compensate by explaining the parameter's purpose or accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and specifies the resource as 'authenticated MAL user's profile', which clearly distinguishes from sibling tools that operate on anime/manga lists. There is no other user-profile tool among siblings, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any exclusions. It does not mention authentication prerequisites or use cases beyond the basic fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but there is no mention of authentication requirements, rate limits, pagination behavior, error handling, or what the response contains. The description is too sparse to convey meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of eight words. Every word contributes meaning, and it is appropriately front-loaded with the core action and target. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too minimal. It fails to convey pagination options, sorting behavior, status filtering, or return value expectations. The description is a bare minimum and leaves significant gaps for an agent to navigate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. The input schema covers 60% of parameters (limit, offset, username have descriptions), but status and sort lack explanations beyond their enum values. Since the description adds no semantic context for these parameters, the overall parameter semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an anime list for a MAL user' uses a specific verb ('Fetch') and resource ('anime list') with a clear scope ('for a MAL user'), which distinguishes it from sibling tools like get_anime_ranking or get_manga_list. It fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context for choosing it over other list/ranking tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. 'Fetch' indicates a read-only operation, but it does not disclose potential issues such as private lists, rate limits, or pagination behavior. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately sized for a minimal tool description, earning a 5 for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain the required status filter, pagination options, or return value structure, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% with descriptions for limit, offset, and username. The description adds no parameter semantics beyond the schema, and status/sort lack explicit descriptions. Baseline applies since the schema covers the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a manga list for a MAL user' – a specific verb and resource. It distinguishes from sibling tools like get_manga or get_anime_list by indicating a manga-specific user list, though it does not explicitly contrast with get_anime_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring a valid username or that status is a required filter, nor does it refer users to sibling tools for other list types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only mentions 'authenticated user's' (implying auth), but does not disclose partial-update behavior, whether new entries can be created, error handling, or idempotency. For a mutation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. While it is terse and could include more detail, it is appropriately concise for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters (most undocumented), no output schema, and no annotations, the one-sentence description is inadequate for an agent to safely invoke the tool. It lacks behavior details, parameter meanings, and update semantics, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (score and anime_id have descriptions). The description refers to 'fields' generically without enumerating the updatable parameters or explaining enum values, numeric ranges, or semantics like is_rewatching vs rewatch_value. It fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update'), the resource ('anime in the authenticated user's MAL list'), and scope. It distinguishes itself from siblings like delete_myanimelist_item and update_mymangalist, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing list entries via the authenticated user's context, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like 'the anime must already be in the list.' No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It states the delete action but does not disclose irreversibility, authentication prerequisites, error behavior, or side effects. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words or redundant details. It front-loads the essential information and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description is minimally sufficient but lacks context about success/error responses, prerequisites, or idempotency. The absence of an output schema and the sparse behavioral detail prevent it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description for manga_id ('MyAnimeList manga ID'). The tool description adds no additional parameter meaning, so based on the high schema coverage baseline, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete one manga from the authenticated user's MAL list.' It uses a specific verb ('delete') and resource ('manga from authenticated user's MAL list'), and the mention of 'manga' distinguishes it from the sibling tool delete_myanimelist_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or alternatives. The name and description imply the purpose, but no explicit usages or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 the operation targets the authenticated user's MAL list, implying authentication is required, but it does not mention reversibility, error behavior, or that existing values may be overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and the target, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters and no output schema, yet the description provides no information about return values, error conditions, or which fields are commonly updated together. This is insufficient for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, and the description adds no parameter-specific information. It merely says 'Update fields' without elaborating on which fields or any parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Update') and resource ('manga in the authenticated user's MAL list'), and the name distinguishes it from sibling tools like update_myanimelist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the user's manga list but provides no explicit guidance on when to use this tool versus alternatives such as update_myanimelist for anime or delete_mymangalist_item for deletions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions the query parameter, without stating whether the operation is read-only, how results are ordered, what the response shape is, or any side effects. For a ranking endpoint, critical behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's core purpose. It is front-loaded and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no annotations, no output schema), the description is incomplete. It does not mention pagination behavior, default ranking order, or the meaning of ranking types, leaving the agent without enough context to set expectations or handle results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers limit and offset with descriptions, but ranking_type is an enum without explanation. The description mentions 'ranking_type' but does not elaborate on its values or how it affects results. Since schema coverage is 67%, the description partially compensates but still leaves ranking_type semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('manga rankings'), which is specific and distinguishes it from sibling tools like get_anime_ranking or get_manga_list. The name and description align without needing further clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ranking data, but it does not explicitly contrast with alternatives like get_manga_list or explain when not to use it. There is no mention of prerequisites or exclusions, landing at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It merely states 'Search MyAnimeList anime' without addressing read-only nature, pagination behavior, rate limits, or handling of no results. The schema reveals limit/offset, but the description does not explain these behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word adds value with no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and complete parameter schema, the description is minimally sufficient for basic use. However, without an output schema or annotations, it does not clarify what the search returns (e.g., list format, pagination details) or how it fits with sibling tools, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so q ('Search query'), limit ('Number of results'), and offset ('Pagination offset') are all documented. The description's 'by title or another text query' adds only a minor clarification for q and does not provide additional semantics beyond the schema, hence a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and clearly identifies the resource 'MyAnimeList anime' as the target. This distinguishes it from sibling tools like get_anime_details (which retrieves specific details) and get_anime_ranking (which retrieves rankings), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is to be used when the agent has a title or text query to search for anime. However, it provides no direct guidance on when not to use it or when to prefer sibling tools like get_anime_details or get_anime_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Fetch' implies a read-only operation, but with no annotations, the description carries the responsibility to disclose behavioral traits such as permissions, rate limits, response size, or error conditions. It mentions optional field selection but offers no further context about API behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core function ('Fetch details for one manga') and the main optional capability ('optionally selecting MAL response fields'). No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description adequately states the primary function and field-selection capability. However, it does not explain what 'details' includes, mention that manga_id is required, or differentiate from get_manga. It relies on the schema for parameter-level details and lacks richer contextual guidance, though it is not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (manga_id and fields). The tool description adds context about 'optionally selecting MAL response fields,' which clarifies the purpose of the fields parameter, but it does not elaborate on valid field values or how to use them. The manga_id parameter is self-explanatory and not enhanced by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches details for one manga, using the specific verb 'Fetch' and the resource 'details for one manga.' It distinguishes from list/ranking siblings by specifying a single manga, but does not explicitly contrast with get_manga, which may also fetch a single manga.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need details for a specific manga rather than a list or ranking. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools like get_manga or get_manga_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add the important context that the tool operates for the 'authenticated MAL user', implying OAuth requirements. However, it does not disclose other behaviors such as rate limits, error handling, or whether the suggestions are deterministic. This is a minimal but not misleading disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It immediately states the core function without any filler, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two pagination parameters and no output schema, the description is adequate but leaves room for improvement. It does not explain the return format, how suggestions are generated, or any authentication failure behavior. The lack of an output schema and the vague term 'suggestions' mean the description could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters (limit and offset) with clear explanations of their roles. The tool description adds no extra meaning about how these params affect the suggestions, but since the schema is complete, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('anime suggestions'), and the target ('authenticated MAL user'). This distinguishes it from sibling tools like get_anime_ranking and get_seasonal_anime, making the purpose immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 any exclusions, prerequisites beyond authentication, or scenarios where another tool would be more appropriate. The sibling names hint at different tools, but the description itself offers no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It says 'Delete' but does not mention that the action is permanent, what happens if the anime isn't on the list, or any specific authentication requirements beyond the phrase 'authenticated user's.' For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler or redundancy. It earns its place by stating the exact action and target in the fewest words possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description covers the core action and implies authentication, but it omits side effects and error cases. It is minimally adequate given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond what the schema provides for anime_id. The baseline of 3 applies because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'anime' and scope 'authenticated user's MAL list,' clearly distinguishing it from sibling get/update tools. It is immediately obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you want to remove an anime from the authenticated user's MyAnimeList. It doesn't explicitly exclude alternatives, but the sibling names (e.g., delete_mymangalist_item, update_myanimelist) make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic fetch action. It does not disclose behavioral details such as sorting, pagination, or returned data format. However, as a read-only operation, the verb 'Fetch' conveys the action clearly without misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that delivers the core purpose without any unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description provides only the primary purpose. It omits any mention of pagination, sorting options, or the response structure, but the schema covers some parameter details. The description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters with descriptions (year, limit, offset), and the description mentions 'season and year' but adds little beyond what is already in the schema. It does not add meaning to sort, limit, or offset parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Fetch'), resource ('anime'), and scope ('released in a specific MAL season and year'). It effectively distinguishes itself from sibling tools like get_anime_list or get_anime_ranking by focusing on seasonal anime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to fetch anime by season and year. It implies the specific use case and distinguishes it from more general list/ranking tools, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 MCP server](https://glama.ai/mcp/servers/MorpKnight/myanimelist-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MorpKnight/myanimelist-mcp)

Score Badge

Copy to your README.md:

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

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/MorpKnight/myanimelist-mcp'

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