AniList MCP Server
Server Quality Checklist
Latest release: v0.8.0
- Disambiguation4/5
The set uses distinct resource prefixes (media, user, studio, thread, activity, list, etc.) and each tool's description explicitly contrasts it with nearest neighbors (e.g., get_user_activity vs get_user_recent_activity vs search_activity). A few convenience shortcuts overlap (get_studio's name search vs search_studio; get_full_user_info vs get_user_profile + get_user_stats) but are clearly cross-referenced.
Naming Consistency4/5All names are snake_case and follow a consistent get_/search_ prefix for reads. Mutation verbs are inconsistent across domains (post_ for activities/threads, add/update/remove for list entries, delete_ for activity/thread/comment, toggle_ for favourites/follow), though each is internally consistent per resource.
Tool Count2/549 tools is well beyond the 25-tool threshold where tool sets become heavy. While the breadth reflects AniList's many domains, the count will force agents to spend significant effort choosing among many similarly-prefixed get_/search_ tools.
Completeness4/5The surface covers CRUD for list entries, activities, threads/comments, plus search for media/users/characters/staff/studios, statistics, notifications, and auth. Minor gaps include no ability to like/unlike content, vote on recommendations, or submit media edits, but these are edge features.
Average 4.6/5 across 49 of 49 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 189 commits in the last 12 weeks
- Last stable release on
- 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds context about activity subtypes and return fields, but does not disclose potential errors, permissions, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, and contains no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter GET tool, the presence of annotations, an output schema, and rich schema coverage, the description provides enough context to select and invoke the tool correctly. It names the resource subtypes and key returned fields, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'id' parameter with a detailed description, including valid ID sources. The description adds no extra parameter semantics, but the schema is sufficient, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a specific AniList activity post by ID, naming the activity types and included fields. It distinguishes itself from list/search tools by emphasizing the 'single' and 'by its ID' scope, but does not explicitly mention sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need one activity post by its ID. The description does not provide explicit when-to-use vs alternatives, though the ID source list in the schema partially compensates.
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 already declare readOnlyHint and openWorldHint, so the description only adds specific metadata field names. It does not disclose additional behaviors like error handling, authentication, or side effects, but the annotations cover the safety profile sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, with no redundant words. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, read-only annotation, and an output schema), the description is nearly complete. It could explicitly state it does not return comments, but the name and content make that obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the `id` parameter is thoroughly documented with examples in the schema. The description merely says 'by its ID' without adding further meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('AniList forum thread') and clearly identifies what is returned (title, body, metadata with specific fields). This distinguishes it from siblings like get_thread_comments or search_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a thread ID and need thread details, but it does not explicitly compare against alternatives. The schema description mentions using search_thread to find an ID, but the tool description itself lacks when/when-not guidance.
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?
The description adds value beyond the annotations by disclosing that login is required and that the comment is posted from the authenticated user's account. It also reveals the dual create/update behavior, which is not explicitly stated in the annotations. This provides useful behavioral context without contradicting the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, then clarifies the create/update variation. It contains no fluff, repeats no schema details, and is immediately scannable, making it an exemplary concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 2 required, all with rich schema descriptions) and the presence of an output schema, the description covers the essential prerequisites (login, authenticated user) and the core create/update capability. It does not mention the reply functionality via `parentCommentId`, but that is thoroughly documented in the schema, so the description is sufficiently complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage across all four parameters, including detailed explanations for `id`, `parentCommentId`, `threadId`, and `comment`. The description's reference to 'or update an existing one by passing its `id`' reinforces the purpose of the `id` parameter but adds negligible new meaning beyond the schema. Thus, the description meets the baseline without significantly enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Post' to identify the action and 'comment on an AniList forum thread' as the resource, clarifying that it creates a new comment or updates an existing one by passing its id. This distinguishes it from siblings like post_thread (creates threads) and delete_thread_comment (deletes comments), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the prerequisite '[Requires login]' and notes the action is performed from the authenticated user's account, giving some usage context. However, it does not explicitly mention when to use this tool versus alternatives such as post_thread or get_thread_comments, nor does it provide exclusions. The usage is implied by the purpose but not fully articulated.
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?
Annotations already declare readOnlyHint, so the description adds useful behavioral details: media limited to 25, sorted by popularity, and includes characterRole (MAIN/SUPPORTING/BACKGROUND). This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero filler. First sentence packs the essential functionality, second gives actionable workflow guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description sufficiently covers the response shape (including media details and roles) and the prerequisite lookup step. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the `id` parameter. The tool description repeats 'by AniList character ID' but doesn't add meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a character's profile by AniList ID, enumerates the specific data returned (name, image, description, media), and differentiates from search_character by noting the ID-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use search_character first to resolve a name to an ID, providing a clear prerequisite and alternative. It doesn't mention all siblings but gives concrete when-to-use guidance.
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 already declare readOnlyHint=true and openWorldHint=true, so the description adds limited behavioral transparency beyond confirming it lists genre names. It provides context about the data source (AniList) but doesn't disclose additional traits like return format or pagination. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the main purpose stated upfront. Every sentence adds value: the first defines the tool's output, and the second explains its practical use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is fully adequate. It explains what the tool returns (genre names), why it's useful (to feed into search_media filtering), and references the relevant sibling tool. This covers all necessary context for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter semantics. The baseline for zero parameters is 4, and the description appropriately focuses on the output and usage rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists every genre name AniList uses to tag anime/manga, with examples like Action, Comedy, Slice of Life. It distinguishes itself from other tools by specifying its purpose in the context of filtering search_media by genre, making the purpose very clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: call it before filtering search_media by genre, to ensure you pass a recognized genre name. While it doesn't explicitly state when not to use it or mention alternatives, the guidance is clear and actionable for its intended use case.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral context by specifying the data is 'across all AniList users' and that it returns a histogram, going beyond just saying 'get stats.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core function, and the second sentence adds a practical usage tip. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, an output schema, and annotations, the description fully covers what the tool does and when to invoke it. The output schema removes the need to explain return values, and the description plus annotations provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for both parameters (id and type), so the description does not need to add much. The hint to use search_media adds a connection between tools but does not deepen parameter understanding beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it retrieves watch/read-status counts and score distribution histograms for an anime/manga across all AniList users. This specific verb and resource distinguish it from sibling tools like get_media or get_media_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use search_media first to resolve a title to an AniList ID, which is a clear usage prerequisite. It does not mention when not to use this tool or name alternatives, but the context is sufficient for selecting it.
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?
The annotations already declare readOnlyHint=true, so the description correctly does not restate read-only safety. It adds valuable behavioral context beyond annotations: replies are nested under parent's childComments rather than appearing as separate entries. This is a non-obvious trait that helps the agent understand the result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the core purpose, and the second adds an essential detail about nesting. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full input schema, output schema, and read-only annotations, the description covers the key operational nuance (nesting behavior). It is sufficient for an agent to select and invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: each parameter (page, perPage, threadId) already has a detailed description in the input schema. The description itself adds no parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and resource ('top-level comments on an AniList forum thread'), scoped by thread ID. It also clarifies the nesting behavior of replies, clearly distinguishing it from thread tools like get_thread or search_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to retrieve top-level comments for a known thread ID) and adds a key caveat about replies being nested. However, it does not explicitly name alternative tools or state when not to use it, though the threadId schema description references search_thread as a lookup method.
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?
Annotations already signal that this is a write, non-idempotent, non-destructive operation. The description adds the login requirement (`[Requires login]`) and clarifies the dual create/update behavior, which is useful context beyond the annotations. No contradictions noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, with the login requirement front-loaded and the core behavior stated efficiently. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and an output schema, the description covers the essential context: what it does, who it affects, and the create/update distinction. No significant information gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters `id` and `text` are already well documented. The tool description only reiterates the `id` semantics for updates, adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Post a new text-status update') and resource ('authenticated user's own AniList profile'), and explicitly mentions the update variant via an existing `id`. This distinguishes it from sibling tools like `post_message_activity` and `delete_activity`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that the tool is for the authenticated user's own profile and can either create a new post or update an existing one by passing an `id`. While it doesn't explicitly name alternative tools, the context is clear enough, and the sibling list includes `post_message_activity` for a different activity type.
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 annotations declaring readOnlyHint and openWorldHint, the description adds valuable behavioral context by noting that each result's bio (`description`) is omitted unless includeDescription is set. This discloses a data-omission behavior that the annotations do not cover, enhancing transparency beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no unnecessary words. Each sentence earns its place, efficiently conveying purpose, relationship to get_character, and an important behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, full schema coverage, annotations, and an output schema, the description is complete. It sufficiently covers the purpose, return value usage, and a key behavioral nuance (bio omission) without needing to reiterate pagination or return format, which are already handled by schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with detailed descriptions, especially for page and includeDescription. The description adds no additional parameter semantics beyond what the schema already provides; it merely repeats the includeDescription effect, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches AniList for characters by name, uses a specific verb ('Search') and resource ('characters'), and explicitly distinguishes the tool from get_character by saying it returns IDs to use with get_character. This is precise and differentiates it from sibling tools like get_media_characters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by indicating the tool returns AniList IDs for use with get_character, implying a search-then-detail workflow. However, it does not explicitly mention alternatives or exclusions (e.g., when to use get_media_characters instead), leaving a slight gap but still giving adequate guidance for an agent.
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 annotations already declaring readOnlyHint and openWorldHint, the description adds the behavioral detail that bios are omitted by default unless includeDescription is set, and that results are IDs intended for get_staff. This enriches the agent's model of the tool without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, return value, and a key behavioral caveat with zero redundancy. All information is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return structures are documented elsewhere. The description covers purpose, key output, and the one non-obvious behavior (bio omission), making it adequate for an agent to invoke correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters at 100%, including detailed descriptions for includeDescription and pagination. The description's mention of bio omission mirrors the schema's includeDescription description, adding no new semantic information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Search' plus resource 'staff members by name' clearly states the action and scope. It effectively distinguishes from get_staff by noting it returns AniList IDs for subsequent lookup, making its role in the workflow explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding staff IDs before calling get_staff, and explicitly recommends get_staff for a single entry's full bio via the includeDescription parameter note. However, it does not explicitly contrast with other search tools like search_character, so it falls short of a full when-not guide.
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 annotations declaring readOnlyHint=true and openWorldHint=true, the description doesn't contradict them and adds useful behavior beyond annotations: it mentions the return format (thread IDs with title/category) and the ability to browse by category without a term. This goes beyond the safety profile supplied by annotations, although it doesn't discuss pagination or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core purpose, the second states the output and downstream usage. Every sentence earns its place with no redundancy, filler, or ambiguity. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a detailed output schema and annotations, the description is complete: it explains what the tool does, what it returns, and how the results are meant to be consumed. It covers browsing and filtering, and the schema handles pagination and parameter specifics. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no param-level details beyond the schema; it only summarizes 'title/body text' (term) and 'restrict to one category' (categoryId). This is a light paraphrase, not additional semantic value, but it doesn't harm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search/browse') and resource ('AniList's forum threads'), with explicit scope ('by title/body text and/or restrict to one category'). It distinguishes from sibling tools by naming the exact thread-related tools it feeds, clarifying that it is the search entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: 'Returns AniList thread IDs ... to use with get_thread, get_thread_comments, post_thread, or post_thread_comment.' This implies when to use it (to find threads) versus when to use other tools, though it doesn't explicitly state exclusions like 'if you already have a thread ID, use get_thread directly.' Still, the context is strong.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the tool returns user IDs for downstream operations, which is valuable behavioral context beyond the annotations. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward search tool with full schema coverage, a read-only annotation, and an output schema present, the description effectively covers what the tool does, what it returns, and how to use it. It doesn't need to restate pagination because the schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: all three parameters (page, term, perPage) have descriptions in the input schema. The description only reinforces that search is by username, adding no new parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('AniList users'), clearly distinguishing it from sibling search tools like search_media or search_character. It also specifies the search key ('by username') and the purpose of the output (IDs for other user tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating that results are AniList user IDs intended for use with specific follow-up tools (profile, stats, list, follow). However, it does not explicitly name alternatives or state when not to use this tool, though the sibling list makes the distinction apparent.
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 annotations indicating a non-read-only, non-idempotent mutation, the description adds the login prerequisite and the toggle semantics (first call follows, second unfollows). This goes beyond the structured annotations and helps the agent predict the state-changing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the essential info: login requirement, action, and repeat behavior. No filler or repetition, and it's front-loaded with the most critical constraint (login).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation with an output schema present, the description covers all necessary context: auth requirement, precise action, and toggling idempotence. The parameter is fully documented in the schema, so nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a highly descriptive parameter note (numeric user ID, no username form, resolve via search_user/get_user_profile). Since schema coverage is 100%, the description doesn't need to add more, and it doesn't—this meets the baseline for schema-heavy documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle following another AniList user') and the scope ('from the authenticated user's account'), which distinguishes it from sibling tools like toggle_favourite. The title also clarifies the follow/unfollow duality, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes the login requirement and explains the toggling behavior ('Calling it again on the same user unfollows them'), which tells users when to use it and what to expect. It doesn't name alternatives, but no other sibling tool provides follow functionality, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-idempotent behavior, and the description adds specific details: markAsRead resets the unread badge as a side effect, and type_in only filters results without affecting which types are generated (controlled by account notificationOptions). It also explains type-dependent field structures, going well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loaded with the login requirement. The first sentence efficiently lists capabilities; the second is a bit dense with nested examples but each part adds value. Slightly complex sentence structure keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the description covers the essential behavior (login, notification types, side effects, type-dependent fields, filter nuance), it is fully complete for an agent to select and invoke the tool correctly. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (page, perPage, type_in, markAsRead) already having detailed descriptions. The tool description doesn't add new parameter-level semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the authenticated user's AniList notifications and enumerates the notification types (airing, likes, replies, mentions, followers, etc.). This distinguishes it from sibling tools like get_user_activity and get_activity, which handle general activity feeds rather than notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says '[Requires login]' and specifies this is for the authenticated user, clarifying when to use it. It doesn't explicitly name alternatives or exclusions, but the focus on notifications versus activity is clear from the description and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond annotations, including the login requirement, the tool's limitation of not exposing the `private` argument (making all posts public), and the fact that it can update existing activities. This directly addresses side effects and limitations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the core purpose, followed by an important caveat. While slightly wordy in explaining the limitations, every sentence provides value and there is no wasted detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (requires login, creates/updates, public visibility), the description covers all key aspects: login, recipient targeting, update capability, privacy warning, and the mutation behavior. The output schema and parameter schemas provide additional technical detail, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in the schema. The description only briefly mentions `id` for updating and `recipientId` for the recipient, but does not add meaningful meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Post a new message-style activity to another AniList user's profile, or update an existing one by passing its `id`.' This distinguishes it from sibling tools like post_text_activity by specifying the recipient and update capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to post a message activity to another user or update an existing one. It also explicitly warns against using it for confidential messages and mentions post_text_activity as a point of comparison, though it doesn't explicitly state alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the login requirement, irreversible deletion, and error behavior on re-deletion. These details go beyond the annotations (which only indicate destructive and non-idempotent) by adding concrete operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the login requirement, and each sentence provides essential caveats without redundancy. This is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 covers purpose, auth, irreversibility, and error behavior. With an output schema present and complete parameter documentation, no significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'id' parameter at 100% with provenance details (e.g., from get_user_activity or post_text_activity). The description itself adds no parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('activity post') with an ownership qualifier, distinguishing it from siblings like delete_thread and delete_thread_comment. The title and description align precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets clear context: it requires login and targets the authenticated user's own activity post. It implies the appropriate use case without explicitly naming alternatives or exclusions, which is strong but not exhaustive.
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?
Annotations already provide readOnlyHint and openWorldHint. The description adds valuable behavioral context by listing the specific categories of relations returned and noting that the relation type is included in the output, which goes beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, the first stating the core purpose and the second a practical usage note. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, read-only, output schema present), and the description covers the essential workflow and output expectations. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by explaining that the ID should be obtained from search_media and that the type parameter determines whether the ID refers to anime or manga, which helps orchestrate the workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get the anime/manga related to a given title') with a specific resource and enumerates relation types (prequels, sequels, side stories, adaptations, spin-offs). This distinctly differentiates it from siblings like get_media or get_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Use search_media first to resolve a title to its AniList ID,' providing a clear prerequisite and workflow. It does not enumerate alternatives or exclusions, but the context makes 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, but the description goes beyond them by disclosing the live ordering behavior ('ordered by rating, not score'), the fact that summary is always included, and that includeBody can return long full-text bodies. This adds meaningful operational context that the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action and ordering detail, followed by practical usage tips. Every sentence serves a purpose and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% coverage), readOnlyHint/openWorldHint annotations, and presence of an output schema, the description still adds essential context: how to resolve IDs, what the response always includes, and when to avoid fetching bodies. This makes the tool fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds some nuance (e.g., 'short excerpt' for summary and 'can be long' for body), but it mostly reinforces what the schema already states. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'List user-written reviews for an anime or manga.' It also clarifies the ordering and includes a prerequisite (search_media), which distinguishes it from sibling tools like get_media_characters or get_recommendations_for_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it tells the agent to use search_media first to resolve a title to an AniList ID, and advises leaving includeBody off unless full text is needed. It does not explicitly name alternatives or when-not-to-use scenarios, but the prerequisite and body-length warning provide solid guidance.
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 readOnlyHint and openWorldHint annotations covering the read-only nature, the description adds a non-obvious behavior: 'No explicit ordering is requested — don't assume results are sorted by role or popularity (unlike get_staff ... which IS popularity-sorted).' This adds useful caveat beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the action and scope, the second provides workflow and ordering caveat. Information is front-loaded and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, prerequisite workflow (search_media), and a key behavioral caveat (unsorted results). The output schema exists, and annotations cover safety and open-world nature, so no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all four parameters (id, type, page, perPage). The description only ties `id` to the search_media workflow but adds no parameter-specific syntax or constraints beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List an anime/manga's staff (director, writer, character designer, author, illustrator, etc.) with their role.' This is a specific verb+resource+scope that clearly distinguishes from sibling tools, especially by noting 'unlike get_staff's reverse-direction lookup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow guidance is provided: 'Use search_media first to resolve a title to its AniList ID.' It also contrasts with get_staff, telling the agent when not to use this tool, making the usage context unambiguous.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral context: results are 'ranked by rating (highest first)', the mediaListEntry field 'requires login' to show list status, and excludeInList filters 'server-side' rather than client-side. This gives the agent a realistic expectation of behavior without repeating annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, tightly packed with essential purpose, prerequisite, and behavioral details. It front-loads the core function, then adds actionable usage guidance. No fluff or redundancy—each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is complete. It covers the main use case, the required setup step (search_media), auth-dependent behavior (login for mediaListEntry), and filtering options. The agent has enough to invoke the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (100% coverage), so the baseline is 3. The description adds value by explaining the workflow for mediaId ('Use search_media first') and the practical trade-off of excludeInList ('instead of checking each one yourself'), which goes beyond the schema's already solid parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List anime/manga AniList users recommend as similar to a given title, ranked by rating (highest first).' This specifies the verb (list), resource (recommendations), and scope (similar to a title), and distinguishes it from sibling tools like get_recommendation (singular) by focusing on a list of recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (after resolving a title via search_media: 'Use search_media first to resolve the title to its AniList ID') and how to use a key parameter (excludeInList to filter server-side). It does not explicitly mention when not to use it, but the workflow guidance is strong.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: it discloses that each result contains full content (text, counts, user, media), eliminating the need for a follow-up call. It also hints at the ability to later re-check likes after liking, which is beyond what annotations state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and each clause earns its place. It packs important usage guidance without unnecessary exposition, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, all rich in schema descriptions, plus an output schema), the description covers the essential context: what it does, what results include, and when to avoid follow-up calls. It does not need to repeat schema details, and the sibling-tool hints (get_activity, get_user_activity) are addressed. The description is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters, including nuanced behavior (e.g., user validation asymmetry, pagination limits). The description only summarizes the parameters at a high level ('optionally filtered to one user and/or one activity type'), which adds minimal value beyond the schema but meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (search/browse) and resource (AniList's activity feed), and explicitly scopes what it covers: list updates, text posts, messages. It also distinguishes from sibling tools by mentioning optional filtering by user and activity type, which get_activity and get_user_activity do not both offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and schema give explicit guidance: it says no follow-up get_activity call is needed, and the user parameter suggests using get_user_activity when only a single user's feed is required without type filtering. It also points to search_user for numeric ID validation, providing clear 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 readOnlyHint and openWorldHint annotations already present, the description adds useful behavioral context: it returns AniList IDs for later use with get_studio, and it is a fuzzy search. It does not contradict the annotations, though it does not go into pagination details (those live in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no filler. Every clause earns its place, including the sibling differentiation and return-value note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage, the presence of an output schema, and annotations for safety, the description covers all needed context: what the tool does, when to use it versus an alternative, and what it returns. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with term, page, and perPage all fully described. The description adds no extra parameter semantics beyond implying that 'by name' refers to the term parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search/browse AniList's animation/production studios by name', clearly identifying the action and resource. It also distinguishes from the sibling get_studio by noting that this tool returns multiple candidates rather than a single closest match, which is strong differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'when you want to see multiple candidates rather than take the closest match' and points out that get_studio's own name param already does the same fuzzy search and resolves partial names. This gives clear when-to-use and an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint and openWorldHint, and the description adds valuable behavioral context beyond those: it warns of a known AniList-side inconsistency where a majority of IDs from get_recommendations_for_media may 404 here, independent of the client. It also clarifies that a 404 does not mean the pairing doesn't exist, which is important runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and usage guidance. However, the caveat about 404 inconsistencies is lengthy, including specific test statistics (7 of 10 tested). That detail is useful but could be more succinct. Overall well-structured, slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID lookup with an output schema present and one integer parameter, the description is complete. It covers purpose, usage context, alternative tools, and failure behavior. Annotations already flag read-only, so no further safety notes are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter 'id' described as 'AniList recommendation ID' in the schema. The description also mentions the ID's role ('by its AniList recommendation ID'), adding minimal extra meaning but enough to reinforce the semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a single AniList recommendation pairing') and the resource (by AniList recommendation ID). It also distinguishes itself from the sibling tool get_recommendations_for_media, noting this is for a single lookup rather than browsing the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use this tool: for re-checking a specific pairing's current rating/userRating after voting, without re-paginating the whole list. It also directs users to get_recommendations_for_media when they need to discover recommendation IDs or browse/list them, providing a clear alternative.
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 already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description's burden is lower. It adds context about the login failure scenario but doesn't elaborate on idempotency or side effects. Value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and provide necessary details without extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema present), the description covers purpose, usage context, and parameter nuances sufficiently. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'redirect_url' is fully described in the schema, and the description adds extra meaning by clarifying that a bare code string is also accepted, going beyond the schema's description of 'full redirected URL'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool completes an AniList login by submitting a redirect URL, using specific verbs and resources. It distinguishes from the sibling tool 'login_anilist' by describing its role in the login flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (when login didn't complete automatically, e.g., on remote/headless hosts), and mentions the prerequisite of having initiated login with 'login_anilist'. It also notes that a bare code string is accepted, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing login requirements, partial-update behavior, full-replace exceptions, server-side validation quirks (rowOrder, timezone, profileColor), and the dangerously surprising advancedScoring reordering hazard. It also warns about silent deletion of custom lists and unrevertable changes, providing crucial safety context that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the purpose and uses parentheticals for critical warnings. It is reasonably concise given the complexity, but the long sentence with nested clauses ('...PLUS ... a third...') could be more readable if restructured into bullets or shorter sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 16 parameters, nested objects, and no required parameters, the description covers all essential non-obvious behaviors: login scope, partial-update semantics, full-replace exceptions, and dangerous side effects. The output schema handles return values, and the description even flags experimental fields and validation failures, making it complete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and highly detailed property descriptions, the schema already does heavy lifting. The tool description adds cross-cutting semantics like 'most fields are a true partial update' and highlights the three full-replace exceptions, which helps the agent understand parameter behavior at a glance, though much of this is also present in individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '[Requires login] Update settings on the authenticated user's own AniList account' which clearly identifies the verb (update), resource (user account settings), and scope (own account). It lists the types of settings, distinguishing it from read-only sibling tools like get_authorized_user and get_user_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires login, targets the authenticated user's own settings, and states the 'only set the fields you want to change' partial-update rule. It explicitly warns about non-partial exceptions (notificationOptions, disabledListActivity, customLists) and advises fetching current state first, but does not name alternative tools for 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: auth requirement, ownership constraint, irreversibility ('cannot be undone'), and non-idempotent error behavior on repeated deletes. This enriches the destructiveHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler. First sentence states the action and scope; second sentence covers consequences and error behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive delete, the description covers auth, ownership, ID source, irreversibility, and repeat-call behavior. Output schema exists, so return value documentation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully documents the id parameter with type and description ('AniList thread ID to delete'). The description adds value by explaining the ID can be obtained from search_thread, get_thread, or post_thread, clarifying provenance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Delete'), resource ('forum thread'), and specific scope ('the authenticated user owns'). It also specifies the required input mechanism (by its ID) and distinguishes from siblings like delete_thread_comment by focusing on threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires login, ownership, and sources for the ID (search_thread, get_thread, post_thread). It does not explicitly name alternative tools or exclusions, so it stops short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations: login requirement, ownership constraint, irreversibility, and non-idempotent error behavior. This fully discloses the behavioral profile of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence conveys all essential information: requirement, action, ownership, ID source, and caveats. No filler words, with important caveats placed at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers prerequisites, ownership, reversibility, and error behavior. Combined with the output schema and annotations, it is fully complete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the id parameter, but the description adds crucial sourcing information (where to obtain the ID) and clarifies that it's the comment owner's ID. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'comment' and states the ownership requirement, clearly distinguishing it from sibling tools like delete_thread and delete_activity. The mention of ID sources (get_thread_comments, post_thread_comment) further clarifies the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite of login and ownership, and explains what happens on repeated calls. While it doesn't name explicit alternatives, the context (delete a comment vs. a thread) is clear enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the returned data structure including staffMedia limited to 25 by popularity with staffRole, adding valuable context beyond the readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with an output schema, the description provides complete context: what it does, what it returns, and how to obtain the required ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the id parameter as an AniList staff ID. The description does not add further meaning beyond reiterating this, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a staff member's profile by AniList staff ID and enumerates the fields returned, distinguishing it from search_staff and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use search_staff first to resolve a name to an ID, providing clear guidance on when to use this tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and dynamic nature are covered. The description adds valuable context: no type filtering, username resolution via an internal lookup, and the absence of a need for search_user. It does not mention error behavior for unknown users in the main description, but that is documented in the parameter schema, so the added value is solid but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, scope, parameter clarification, and alternative-tool guidance with zero filler. The information is densely packed and front-loaded with the primary purpose before moving to alternatives, making it easy for an agent to quickly grasp the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists to explain return values and the annotations cover safety semantics, the description completes the picture: it states what the tool does, how the username parameter works, pagination context is in the schema, and it names the exact alternatives for nearby use cases. The tool is relatively simple (3 params, flat output), and the description covers all necessary decision points.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that the 'user' parameter accepts an exact username directly (resolved internally) and by contrasting behavior with search_activity's user filter. This enrichment of the user parameter justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List recent AniList activity posts from a specific user' – a specific verb, resource, and scope. It also notes that all activity types are included and no type filter is applied, which differentiates it from sibling search_activity and get_user_recent_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use alternatives: 'Use search_activity instead if you want to restrict to one activity type... or browse without pinning to one user' and 'Use get_user_recent_activity instead if you just want a quick, fixed-size (5-item) recent snapshot.' It also advises that search_user is unnecessary for exact usernames, providing clear decision guidance.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds behavioral context: full content not just IDs, no type filter (even message activity received), fixed count, and that unknown IDs/usernames error rather than returning empty results (from param description). It also mentions an extra internal lookup for username resolution. This adds substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with every clause earning its place: purpose, type coverage, count fixity, alternative, and parameter guidance. No fluff, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers all needed context: exact behavior (count, type coverage, full content), error semantics, alternative tool, and parameter resolution. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the 'user' parameter 100%, including the accepted types and error behavior. The description adds practical semantics: 'Accepts an exact AniList username directly — no need to call search_user first' and clarifies the cost of username resolution, which complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get an AniList user's 5 most recent activity posts' and clarifies scope with details like full content, all activity types, and fixed count. It also distinguishes from sibling get_user_activity by explicitly naming that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs alternatives: 'use get_user_activity for a paginated full feed instead' and when to consider search_user for partial/fuzzy names. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=false), the description adds critical behavioral details: it 'cannot be undone' and that calling it again on an already-deleted id 'errors rather than silently succeeding.' This enriches the annotation signal with concrete consequences, which is exactly what behavioral transparency should provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loaded with the primary purpose and immediately followed by essential caveats (login, ID source, irreversibility, error behavior). Every phrase earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with a full schema and annotations, the description covers all necessary context: authentication requirement, scope (own list), ID lookup path, irreversibility, and non-idempotent error behavior. The output schema exists but doesn't require explanation, as this is a straightforward mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes listEntryId as 'The list ENTRY id to delete (not the media id)' (100% coverage). The description adds practical guidance on where to obtain this ID ('get it from get_user_list'), which goes beyond the schema and helps the agent source the correct value, so a slight premium over the baseline of 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and clearly identifies the resource as 'an entry from the authenticated user's own AniList list.' It also distinguishes the correct identifier type ('NOT the media id') and references get_user_list, making it immediately clear which sibling tool (e.g., update_list_entry, add_list_entry) this contrasts with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: login is required, the entry must be from the user's own list, and the ID must be obtained from get_user_list. While it doesn't explicitly mention alternatives like update_list_entry, the purpose is unambiguous and the prerequisite is stated, effectively guiding when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world, and the description adds substantial behavioral context: adult results are included by default unless sfw=true, silent no-op behavior for onList when not logged in, season matching every year rather than just current year, and upstream pagination failure at deep pages. These go well beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph that front-loads the core functionality, then adds essential caveats (NSFW inclusion, ID output, term-less browsing) without listing all 25 parameters. Every sentence contributes value and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 25 parameters, a rich output schema, and annotations, the description is remarkably complete. It covers primary usage modes, important edge cases (silent mismatches, login requirements), integration with other tools, and points to schema for further detail. No significant information gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a detailed description. The tool description mainly references key parameters (sort, sfw) and relates them to use cases, but adds no new semantic detail beyond the schema's own parameter explanations. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as searching AniList for anime/manga by title or filters, and distinguishes it from sibling search tools (search_character, search_staff, etc.) by specifying the resource type. It also differentiates from get_media by noting that this tool returns AniList IDs for use with other ID-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use term-less browsing by ranking vs. title search, and directs users to get_media for full synopses. Names alternative tools for genres (get_genres) and tags (get_media_tags), and explains the default sort behavior without a term. Also advises on includeDescription to avoid token bloat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation, but the description adds critical behavioral details: response echoes stored values, advancedScores and customLists are zeroed/replaced rather than merged, and login is required. This goes beyond the annotation flags to inform the agent of side effects and verification steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence delivers essential information (auth, ID distinction, partial update guidance, response verification). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 14 params and nested objects, the description covers the key operational context: how to identify the entry, the partial-update model, special zeroing behavior, and the need to verify responses. Output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The tool description adds crucial parameter behavior for advancedScores and customLists (zeroed/replaced, not merged), which is not obvious from the schema alone. This lifts the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing entry on the authenticated user's own AniList list by list-entry ID, explicitly distinguishing from media ID. It effectively contrasts with sibling tools like add_list_entry by specifying the exact action and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: requires login, update existing entry, only set fields to change, and points to get_user_list/add_list_entry response to obtain the list-entry ID. It lacks explicit 'do not use for' exclusions, but the context and sibling names make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rich behavioral details beyond annotations: ranking window semantics, nextAiringEpisode availability only for currently-releasing anime, mediaListEntry returning null if not on the user's list, batch behavior with null placeholders in order-preserved arrays, and the unbounded streamingEpisodes field. Annotations (readOnlyHint, openWorldHint) are consistent with the description; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but front-loaded with the core purpose, and every sentence serves a purpose (returned fields, special cases, usage guidance, return format). It is somewhat dense, but given the tool's complexity and the need to cover rankings, login requirements, and batch behavior, the length is justified. A slight deduction for the long list of fields and asides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential context: what the tool does, when to use it (and when not to, via search_media guidance), authentication requirements, batching semantics, and return type variance. The output schema exists and covers return fields, so the description need not enumerate them. It is fully adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context: the 25-ID cap is tied to codebase conventions, uncapped batches could be huge, and includeStreamingEpisodes is off by default because AniList doesn't paginate it. It also explains the return shape conditional on `ids` being a scalar vs. array. These insights go beyond the schema descriptions, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: "Get detailed information about one or more anime or manga by their AniList ID(s)". It enumerates the returned fields (title, format, status, counts, genres, score, synopsis, dates, rankings) and explicitly distinguishes from sibling tools like search_media by stating that search_media should be used first to resolve titles to IDs. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: "Use search_media first to resolve a title to its AniList ID." It also clarifies when login is required (for mediaListEntry) and when includeStreamingEpisodes should be enabled (warning that it can return hundreds of entries). This sets clear usage boundaries relative to sibling tools like search_media and get_media_tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: the 50-result fixed cap with silent omission (no pagination), the difference in returned object shapes, and the lighter fetch nature. This adds substantial context not covered by readOnlyHint/openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit dense, with a long second sentence, but every clause carries essential information. It is front-loaded with the core behavior and then covers caveats, making it efficient despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the cap, pagination absence, silent omission, return shape, lighter fetch, and includeDescription behavior. Combined with the output schema and annotations, it is fully sufficient for an agent to use the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage, but the description adds valuable semantics: kind determines character-shaped vs staff-shaped objects, and includeDescription is explained with a token-burn warning and alternative. This goes beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists AniList characters or staff with birthdays today, using a specific verb ('List') and resource. It also distinguishes itself from sibling tools like get_character/get_staff by explicitly noting it is a lighter fetch without filmography.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use this tool for lightweight birthday lookups, and call get_character/get_staff by ID for full roles/works and bio. It also warns not to interpret missing filmography as 'none', providing clear when-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds critical behavioral context beyond annotations, warning that stats aggregation can lag and may return all-zero for active accounts, instructing agents not to misinterpret such results. This is a valuable caveat not derivable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and each sentence provides value. Slightly dense with multiple clauses, but no fluff. The 'confirmed live' anecdote is a bit wordy but reinforces the caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description addresses purpose, exact parameter usage, data freshness caveats, cross-checking guidance, and alternatives. For a single-parameter read-only tool with these quirks, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'user' parameter is documented as ID or username). The description adds useful semantic nuance: it must be an exact username, no need to search first, and partial/fuzzy names require search_user. This helps the agent use the parameter correctly beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get an AniList user's anime/manga statistics' and lists specific data fields (counts, mean score, time watched, episodes/chapters/volumes consumed). It also distinguishes from siblings by explicitly mentioning no need for search_user and directing to get_full_user_info for profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: 'no need to call search_user first unless you only have a partial/fuzzy name' and 'Use get_full_user_info instead of also calling get_user_profile separately.' It also advises cross-checking get_user_list if results are zeroed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations by disclosing upsert semantics, default-only-for-new-entries behavior, response echoing for verification, and the zero/replace behavior of `advancedScores` and `customLists`. It also reveals subtle API quirks (e.g., API defaults status to CURRENT while the UI defaults to PLANNING), which is exactly the kind of behavioral transparency needed for a mutation tool with openWorldHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries critical information about defaults, upsert, response verification, and pitfalls. It is front-loaded with the required login and core purpose, then logically flows through prerequisites, behavior, and caveats. While dense, it earns its length for a tool with 14 parameters and subtle API semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 params, nested objects, output schema), the description is complete. It covers safety (requires login), workflow (search first), edge cases (upsert, defaults), and verification (response echoing). The output schema handles return values, so the description needn't explain them. It addresses all major scenarios an agent would face.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the status default nuance per new vs existing entry, clarifies that `customLists` replaces rather than merges and requires pre-existing lists, and warns about `advancedScores` zeroing omitted categories and positional matching at read time. This enriches parameter usage significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Add an anime/manga to the authenticated user's own AniList list.' It distinguishes itself from siblings by explicitly covering upsert behavior (update-if-exists), which differentiates it from get_user_list and complements update_list_entry. It also states the prerequisite of using search_media first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use search_media first to resolve the title to its AniList media ID' and 'Use get_user_list first to check for an existing entry if you need a guaranteed-fresh one.' It explains when defaults apply (new entries only) versus when they don't (existing entries keep previous values), giving clear context on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the login requirement ([Requires login]) and explains that this tool returns the authoritative current values needed for full-replace updates. This is valuable behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides rich, relevant usage caveats. While long, every sentence carries operational significance, though it could be tightened by moving some update_user details to that tool's own description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, read-only) and the rich output schema, the description covers the purpose, auth prerequisite, workflow context, and specific scenarios where this tool is essential. It's complete for an AI agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description clarifies that the target account is determined via login state rather than a parameter. It explains how the authoritative identity is established (via login_anilist/ANILIST_ACCESS_TOKEN), adding meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the profile of the currently authorized AniList account, using a specific verb and resource. It explicitly differentiates from other user-focused tools (e.g., get_user_profile) by targeting the authorized account and ties it to login_anilist/ANILIST_ACCESS_TOKEN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: to confirm which account is connected, and as the authoritative prerequisite fetch before update_user calls involving specific fields. It even explains the array-replacement and positional-index risks that necessitate reading current values first, which strongly steers usage toward this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint and openWorldHint, but the description adds meaningful behavioral context: account settings are returned regardless of authentication, and statistics may be stale due to AniList aggregation lag. These are non-obvious traits that help the agent anticipate edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, then adds usage alternatives, auth behavior, and a caveat. Each sentence earns its place with no redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema, the description covers all essential aspects: what the tool returns, how it differs from siblings, when to use it, and potential data staleness. There are no gaps for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the parameter ('AniList user ID, or username'), so the baseline is 3. The description adds value by clarifying that an exact username works directly without needing search_user, and that partial/fuzzy names require a prior search. This extra guidance goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get an AniList user's profile AND statistics in a single call'. It also explicitly distinguishes it from siblings by saying 'use this instead of calling get_user_profile and get_user_stats separately', making the unique value obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct usage guidance: when to use this tool vs. alternatives ('use this instead of calling get_user_profile and get_user_stats separately') and when not to need search_user ('no need to call search_user first unless you only have a partial/fuzzy name'). This is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true in annotations, the description adds valuable behavioral context: results are not guaranteed to be grouped by role or sorted by popularity, with a live example that Main-role characters can appear later than Supporting ones. This discloses non-obvious behavior beyond schema/annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then workflow, then the key ordering caveat. Every sentence earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description sufficiently covers what is returned (characters, roles, voice actors), how to prepare the ID, and the critical ordering uncertainty. The agent has enough context to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning for the 'id' parameter by telling users to resolve titles via search_media, and clarifies type-specific output (voice actors only for anime), which goes beyond the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List an anime/manga's characters' with role and voice actors. This clearly distinguishes it from sibling tools like get_character (reverse lookup) and search_media (title resolution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to 'Use search_media first to resolve a title to its AniList ID', establishing a clear workflow. It also contrasts with get_character/get_staff's reverse-direction lookup, helping the agent know when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral details beyond the readOnlyHint and openWorldHint annotations: pagination is required (~425 tags), page/perPage parameters cannot return all at once, tag names are case-sensitive, and unrecognized names silently match nothing (confirmed live). It also mentions the response includes category and adult-content flag, which is additional useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all relevant and non-redundant. It front-loads the purpose, then provides pagination behavior, then the specific use case with a caveat. No fluff or repetition of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's complexity: what it lists, how pagination works, why it matters, and a critical usage pitfall (case-sensitivity and silent no-match). With an output schema present, the description doesn't need to explain return values, and this description is complete for selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both page and perPage have descriptions), so the baseline is 3. The description adds context by explaining the ~425 tags total and advising to use pagination rather than expecting all in one response, which reinforces the purpose of the parameters. It doesn't add detailed syntax beyond the schema, but the contextual addition earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every descriptive tag AniList uses on anime/manga, with examples ('Time Skip', 'Tragedy', 'Reincarnation') and distinguishes from genres. It also implies the specific use case for search_media's tag_in, differentiating it from sibling get_genres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool: to look up a tag's exact name before passing it to search_media's tag_in. It also mentions pagination necessity due to ~425 tags and notes that names are case-sensitive, providing both context and a specific use case. While it doesn't explicitly say 'use get_genres for genres', the 'finer-grained than genres' implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints, and the description adds practical behavior details: default to last 7 days, newest-first ordering, and the AniList-side perPage cap that nullifies any concern about the tool's own limit. These go beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core function, followed by usage guidance and a useful quirk. Every sentence adds distinct value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with an output schema already present, and the description fully covers purpose, use cases, defaults, and a behavioral quirk. Nothing important is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by explaining that defaults correspond to a 7-day window and that page/perPage are used to 'go further back', linking them to time range rather than just pagination mechanics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets AniList's site-wide statistics (new users/anime/manga daily counts) in newest-first order. It distinguishes itself from siblings by explicitly noting this is not for anime data, unlike get_media_statistics or get_user_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('useful for questions about AniList's growth/activity') and when not to ('not for anime data'). It also explains how to access historical data via pagination, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld, but description adds meaningful beyond-annotation context: explicitly states account settings are included for any user, not just the authenticated caller. This removes potential ambiguity about data accessibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: scope, transparency detail, input guidance, and alternative tool recommendation. No redundancy or filler; concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description covers purpose, contents, special behavior, and alternatives. It is fully self-sufficient without requiring external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter with 'AniList user ID, or username' (100% coverage). The description adds value by explaining that an exact username is accepted directly, eliminating the need for a preliminary search, which clarifies expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a clear verb+resource: 'Get an AniList user's public profile' and enumerates specific contents (name, about, avatar, donator status, account settings). It differentiates from siblings by explicitly naming get_full_user_info and search_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: states exact usernames need no search_user first, and suggests get_full_user_info when statistics are needed. Also clarifies that settings are not viewer-gated, so the tool is appropriate for any user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses prerequisites (app registration, callback URL, env vars), warns that auto_capture is not a reliable detector of local browser access, and explains the remote/SSH headless scenario. This is rich behavioral context that prevents misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, and every subsequent sentence delivers essential prerequisites, flow steps, or a pitfall warning. The length is justified by the complexity of the OAuth flow, and there is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the OAuth orchestration, the presence of an output schema, and the need to coordinate with submit_anilist_redirect, the description is complete: it covers setup, the returned URL, automatic vs manual completion, and the meaning of the auto_capture field. No ambiguity remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and the baseline is 4. The description adds context about environment variables and port configuration, but since there are no input parameters to document, it cannot add more beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Authorize the personal-list and social tools with your AniList account (one-time)', which is a specific verb and resource. It clearly distinguishes this from the follow-up tool submit_anilist_redirect, establishing the tool's role as the initial authorization step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the complete flow: calling this returns an authorization URL, then either auto-completes if browser is local or instructs to pass the redirect URL to submit_anilist_redirect. It explicitly covers when to use the alternative and the conditions that determine which path to follow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the 'confirmed live' nature, the soonest-airing ordering, and the notYetAired parameter's behavior of swapping to past-only results. It also reveals that manga IDs are rejected with the same not-found error as nonexistent IDs, preventing agent confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, usage modes, and edge-case behavior with no filler. The structure front-loads the main function and logically nests the optional mediaId usage and the manga-related error note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema present, annotations present), the description covers all necessary operational aspects: scheduling modes, ordering, live status, manga exclusion, and error semantics. With a rich output schema available, it is complete without needing to restate return formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% parameter coverage, the description adds essential semantic guidance: omitting mediaId yields the site-wide schedule, while passing it gives a single title's next air time. It also explains the effect of notYetAired and the manga ID error nuance, which are not fully covered by the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns anime episode air times, sorted by soonest-airing first, and distinguishes site-wide vs specific-title modes. This clearly separates it from sibling tools like get_media or search_media, which return different types of media information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to omit mediaId (site-wide schedule) vs when to pass it (specific title), and tells the user to obtain the ID from search_media/get_media. It also states the anime-only restriction and the resulting not-found error for manga IDs, giving clear usage boundaries and expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: a fixed cap of 10 titles (not paginated), the fuzzy search behavior of the name parameter, and id precedence. These are not evident from readOnlyHint/openWorldHint or the schema, adding significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with each sentence serving a purpose. It is front-loaded with the primary function, followed by limitations, usage nuances, and a clear alternative. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no required fields, output schema present) and the annotations, the description covers all relevant contextual aspects: what it returns, the cap, the fuzzy matching, the alternative tool, and input precedence. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes both parameters (100% coverage), the description adds critical semantic information: the mutual exclusivity (provide this or that), the fuzzy matching nature of name, and the precedence rule when both are given. This goes well beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a studio's profile (name, animation studio status) and top 10 produced titles. It explicitly differentiates from the sibling tool search_studio, noting when one should be preferred over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. search_studio ('reach for search_studio instead only when you need to browse multiple candidates'). It also clarifies the behavior with partial names and the precedence of id over name, giving clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, the description discloses pagination semantics (chunk counts across all statuses combined), the need to check hasNextChunk, and AniList's ~11,000 entry cap for older entries. This is valuable behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose in the first sentence, then covers usage and pagination in clearly separated clauses. Every sentence adds operational value—no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated external-API tool, the description covers grouping, pagination loop (hasNextChunk/increment chunk), API cap, and username-handling. With an output schema present, there is no missing return-value information; the description is fully self-sufficient for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema descriptions cover all four parameters 100%, the tool description enriches 'chunk' and 'perChunk' by explaining they are AniList's own pagination mechanism and that counts are across ALL statuses combined. It also clarifies the 'user' parameter accepts an exact username directly, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Get a user's AniList anime or manga list, grouped by status/custom list', enumerating returned fields (status, score, progress, dates). It also clarifies it works for any public/unlisted user, distinguishing it from user-profile tools like get_user_profile or get_full_user_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells agents when not to call search_user: 'Accepts an exact AniList username directly — no need to call search_user first unless you only have a partial/fuzzy name.' Also frames pagination usage with chunk/perChunk and hasNextChunk, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: requires login, response omits certain fields, sticky/locked silently no-op without moderator permission, and categories/mediaCategories are full-replace not merge on update. This is rich, non-obvious context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but every sentence earns its place, covering purpose, usage guidance, and critical caveats. It is front-loaded with the main action and structured into a coherent flow, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is exceptionally complete: it covers authentication, create vs. update modes, pre-check guidance, response limitations, and silent failure modes. The presence of an output schema does not reduce the need for these descriptive clarifications, and the description delivers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds critical semantics: body/title are required on create but optional on update, categories required on create, full-replace behavior on update, and mod-only effect for sticky/locked. This goes far beyond the schema's baseline descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: posting a new forum thread to the authenticated user's own account or updating an existing one by passing its id. It distinguishes itself from sibling tools like post_thread_comment, search_thread, and get_thread by focusing specifically on creating/updating threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using search_thread first to check for duplicates before posting, and instructs calling get_thread with the returned id to confirm category/sticky/locked changes. This gives clear when-to-use and alternatives, exceeding baseline guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-idempotent, and non-destructive, which the description aligns with. It goes beyond by disclosing that the response returns the entire favourites list, that AniList does not validate kind-id pairing, and that there is a confirmed read-after-write lag. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds operational value: purpose, toggle behavior, response shape, id resolution, validation gap, and lag. It is front-loaded with the core purpose and follows with necessary caveats, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers login requirement, exact toggle semantics, response list shape, parameter resolution process, a serious API validation gap, and a data consistency caveat. With an output schema present, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already provides descriptions for both parameters, the description adds essential semantics: the id must be resolved from a tool matching the kind, and because AniList does not validate the match, incorrect pairings silently succeed. This is critical usage knowledge not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'toggle' and clearly identifies the resource: an anime, manga, character, staff member, or studio in the authenticated user's AniList favourites. It distinguishes this from sibling tools by focusing on the favourites toggle action, not list entries or user follows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: resolve the id via search_media/get_media, search_character/get_character, etc., based on kind. It also warns against reusing IDs and explains the toggle behavior (calling again un-favourites). The read-after-write lag note gives additional guidance for verification.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Grinv/anilist-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server