Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond annotations: deletion is irreversible, the API returns success even when the item was never on the list, and success is not proof of prior existence. This is valuable, non-obvious behavior that agents need to interpret the result correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: the main action, irreversibility, the surprising success-response behavior, the advice to confirm via get_my_anime_list, and the auth requirement. It is dense but not bloated, and the most important semantics are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mutation tool with an output schema and meaningful annotations, the description fully covers purpose, auth, destructive behavior, idempotency semantics, and a verification path. There is no meaningful missing context that would prevent an agent from using the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for anime_id, including its semantics, source, and naming caveat. The tool description itself adds no parameter-specific meaning, which is fine because the schema carries the full burden—exactly the baseline scenario.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Remove') and a clear resource ('anime entry from the authenticated user's list'), and the title/name distinguishes it from sibling delete_my_manga_list_item. It immediately answers what the tool does and for whom.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states the operation happens on the authenticated user's list, requires login, and advises checking get_my_anime_list when confirmation of prior existence is needed. It does not explicitly name delete_my_manga_list_item as the manga alternative, but the title and sibling context make that distinction obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations already declare destructiveHint and idempotentHint, the description goes beyond them with a specific, non-obvious behavioral fact: 'deleted: true whenever MAL accepts the request — including when the manga was never on the list to begin with.' It also warns that the action cannot be undone and clarifies that success does not prove prior existence, which is critical, non-obvious information for an agent at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action is front-loaded in the first sentence, and each subsequent clause earns its place by disclosing irreversibility, the idempotency edge case, a confirmation alternative, and the auth requirement. The middle sentence is dense with parentheticals, but nothing is wasted filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive write with a rich output schema and annotational context, the description covers purpose, irreversibility, edge-case return semantics, a verification path, and authentication requirements. Combined with annotations and schema, there's no meaningful gap an agent would need to guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; the manga_id property is well documented in the schema with type, bounds, sourcing guidance, and a naming mismatch caveat. The description text itself adds no separate parameter semantics, so the baseline 3 holds since the structured schema is doing the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb 'Remove' and an explicit resource ('manga entry from the authenticated user's list'). The resource scope cleanly distinguishes it from both the read-only get_* siblings and from its direct counterpart delete_my_anime_list_item, while the name and title reinforce that it targets manga, not anime.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names the sibling get_my_manga_list as the correct alternative when confirmation is needed ('check get_my_manga_list first if you need to confirm'), and states the login prerequisite. It doesn't explicitly contrast with update_my_manga_status or delete_my_anime_list_item, but the scope is clear enough that this is a minor gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations declare readOnlyHint and openWorldHint, the description adds substantial behavioral context beyond those flags: the moreinfo field being usually absent, the trailer being only the single main URL, the sfw/sfw_strict filters applying only to the relations list and not the anime itself, and the transparent fallback to the official MAL API with a precise list of omitted fields. This level of detail exceeds what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average, but every sentence earns its place: one sentence defines the core return payload, then each subsequent sentence addresses a genuine edge case (moreinfo optionality, trailer limitation, id sourcing, sfw semantics, fallback degradation). The most important information is front-loaded, and the technical fallback detail is logically placed at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to document return shapes, and it does not waste space doing so. It instead covers the operational aspects an agent needs: the fallback behavior when Tenrai is unavailable, which fields are lost in that fallback, the id acquisition path, and the subtle scoping of the sfw flags. Nothing an agent would need to correctly invoke this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all three parameters 100%, so the baseline is 3. The description still adds meaning by clarifying that sfw/sfw_strict do not filter the requested anime itself but only its relations list, and by flagging the fallback API behavior for parameters like sfw. The id parameter is contextualized by the 'from search_anime' guidance, adding temporal semantics beyond the schema's numeric type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource — 'Get full details for one anime by mal_id' — and enumerates the concrete fields returned (synopsis, score, genres, studios, streaming links, external links, synonyms, related entries). It clearly distinguishes itself from siblings by telling the agent to use get_anime_videos for video content, and the 'get full details for one anime' framing sets it apart from search_anime, get_top_anime, and get_anime_schedule.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing guidance: 'Obtain the mal_id from search_anime first' tells the agent the prerequisite workflow, and 'use get_anime_videos for every promo/episode-preview/music video' names the alternative and the exact condition for choosing it. It also explains when the sfw parameters apply versus when they don't, leaving no ambiguity about 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the 'List' verb aligns with that. The description adds useful scope around roles and voice actors, but does not disclose extra behavioral traits like pagination, missing-id handling, or malformed-data behavior. Since output schema exists, this is acceptable though minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, purposeful sentences with no filler. The first sentence states the action and content, and the second gives actionable guidance for obtaining the required input. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool, and the description leaves no important gap: it identifies the target resource, the result's contents, and how to acquire the required mal_id. The output schema and annotations carry the remaining return-value and safety context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the only parameter as 'MyAnimeList numeric ID.'. The description's 'by mal_id' reinforces this but does not add new constraints, units, examples, or meaning beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List'), a specific resource ('characters of an anime'), and the key output contents ('roles and Japanese voice actors'). The qualifier 'by mal_id' and the pointer to 'search_anime' make it easy to distinguish from manga, people, or general-character tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly directs the agent to obtain the required id from 'search_anime', which is a concrete usage prerequisite. It does not name the manga equivalent as an alternative, but the anime-specific wording and id source provide enough selection context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely new behavioral context with the ~100-per-page pagination size and the presence of filler/recap flags in the results. It does not describe ordering or error behavior, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and result fields, followed by the pagination constraint and the prerequisite. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose; with only two parameters and a full schema, the description covers everything an agent needs — what it lists, how pagination works, and where the required id comes from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining that `page` exists specifically for long-running series and that `id` is a MyAnimeList ID obtained from search_anime, adding meaning beyond the schema's terse field docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List an anime's episodes') and enumerates the fields returned (titles, air dates, filler/recap flags). It is clearly distinguishable from get_anime (details) and from search_anime, which is named as the way to obtain the id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to search_anime for the mal_id and tells it to use `page` for long-running series. No explicit when-not guidance versus get_anime, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds that sfw/sfw_strict drop genres from the list itself, which is a useful behavioral clarification about output rather than input filtering. It says nothing about result size, caching, or ordering, so the added context is modest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero waste, front-loaded with what is returned and immediately followed by the reason to call it. No redundancy with the schema beyond a brief needed clarification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values need not be described. Purpose, cross-reference to search_anime, and filter semantics are all present, making the definition sufficient for correct invocation. A minor gap: no hint that omitting `filter` returns all four tag kinds in one payload.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already carries a detailed explanation of the sfw vs sfw_strict distinction. The description's restatement of those flags adds only slight value (clarifying that whole genres disappear from the returned list), so the schema continues to do the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List anime genres/themes/demographics with their MAL IDs') and names the taxonomy kinds it covers. This clearly distinguishes it from the sibling get_manga_genres and from search_anime without needing the schema opened.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this to discover the numeric IDs that the `genres` parameter of search_anime expects. It covers the main case and the alternative, but gives no when-not-to-use condition (e.g., that a free-text search may be faster if the genre name is already known).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and open-world semantics, so the description's added value is the disclosure that it returns stack metadata only and that no official-API fallback exists, meaning Tenrai must be reachable. That availability caveat is genuinely useful, though it does not cover result volume or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and resource, then prerequisites, return scope, and availability caveat in a logical order. It is a bit dense at three clauses plus a caveat, but nearly every sentence carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full parameter coverage, the description only needs to frame purpose, routing, and caveats, which it does. Only minor gaps remain, such as how large result sets are returned in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all ten parameters (sfw vs sfw_strict, official/spoilers/challenges tri-state enums, order_by/sort interaction) are already documented in the schema. The description adds only the origin of the required id; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (public MyAnimeList Interest Stacks) plus the binding scope (that include a given anime by mal_id). It is clearly distinguishable from get_interest_stack (which returns entries of one stack) and get_manga_interest_stacks (the manga counterpart), both of which are named or implied in the routing sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case ('what do people group this with', human-curated recommendations vs vote counts), a prerequisite ('Get the mal_id from search_anime'), and a handoff rule ('pass a stack's own mal_id to get_interest_stack'). An agent knows when to call this and what to do next.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and open-world, so the description adds non-obvious empirical behavior: sfw/sfw_strict filtering 'can cut the result down sharply (not necessarily to zero) rather than being a no-op.' That is genuine context beyond the schema. It's slightly redundant with the sfw/sfw_strict schema text, keeping it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what it returns, then usage, then the sibling alternative, then the sfw caveat. Each sentence carries information, though the sfw sentence is long and partly retreads schema text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values needn't be explained, yet the description still previews the fields. Combined with the mal_id sourcing hint, sibling routing, and filter caveat, an agent has everything needed to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description still adds value by framing the id as a MAL id sourced from search_anime and by characterizing the real-world effect of the sfw flags, which the schema states only as a rule, not as an outcome.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: 'List recent news articles about an anime (by mal_id)' and enumerates returned fields (headline, date, author, excerpt). It is clearly separable from get_news and get_manga_news without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the question shape it answers ('what's new / any announcements'), names the prerequisite path ('Get the mal_id from search_anime'), and explicitly routes to the alternative get_news for site-wide feeds. When-to-use and when-not-to-use are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial operational detail: ordered by votes, capped at 25 with no pagination, and a transparent fallback that changes result count, ordering, and ignores sfw/sfw_strict. That is rich behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph but front-loads the main purpose, then alternatives, then filter behavior, then fallback. Every sentence earns its place with no redundant or vague filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values. It covers the key operational caveats (cap, no pagination, ordering, fallback limitations) and points to the correct source for the required id. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents id, sfw, and sfw_strict thoroughly. The description briefly reiterates that sfw/sfw_strict filter NSFW entries, adding slight context ('of the recommendation list itself'), but does not add syntax or format guidance 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get community recommendations for anime similar to the given mal_id') along with scope, ordering, and cap. Explicitly distinguishes from siblings get_top_anime and get_recent_anime_recommendations, so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance: 'Get the mal_id from search_anime' and names the two alternatives with the conditions that select them. Also describes the fallback path (Tenrai unavailable) so the agent knows what to expect in that case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/open-world, so the description carries real weight: it discloses 1200-character truncation, the default sort (Tenrai's most_helpful), the ~20-per-page listing size, and critically that `limit` does not fetch additional pages. That last point prevents a common misuse loop and is 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and return fields, then the pagination caveat, then the prerequisite — a sensible order. It is dense with parentheticals and backticked field names, which slightly hampers scanning, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter read tool with an output schema, everything an agent needs to call it correctly is present: the ID source, page vs limit semantics, filter-before-cap ordering, and default sort. Return value structure is left to the output schema, as appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds ordering semantics the schema omits: `sort`/`preliminary`/`spoilers`/`sentiment` filter and order the underlying set *before* the `limit` cap is applied. The limit-vs-page distinction is also restated in operational terms rather than schema terms.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get user reviews for one anime (by mal_id)') and immediately enumerates what a review contains, so the agent knows exactly what payload to expect. It also distinguishes itself from get_manga_reviews by calling out that `episodes_watched` is not `chapters_read` (manga-only), which disambiguates a near-identical sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete prerequisite chain ('Get the mal_id from search_anime') and explains how to page further ('use `page` for Tenrai's own ~20-per-page listing'), which is the main decision an agent faces. It stops short of saying when to prefer get_manga_reviews or when reviews are unavailable, but the routing context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/openWorld, and the description adds genuinely useful behavior: `broadcast` is only populated for currently-airing shows, and the `unknown`/`other` buckets exist for slot-less entries. It does not cover rate limits or result-shape caveats beyond that, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the core purpose and then the filter and pagination notes. Every clause carries information, though the parenthetical about the unknown/other buckets overlaps with the schema's own wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and all seven optional parameters are documented in the schema. The description covers the remaining ambiguity an agent would face: the JST time basis, when `broadcast` is absent, and pagination defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains day, sfw, kids, page, limit, unapproved and the sfw/sfw_strict distinction in detail. The description restates the weekday/unknown/other semantics and the 25-result default without adding syntax or behavior the schema lacks, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the anime broadcast schedule') and adds a meaningful qualifier (air times in JST, optional weekday filter) that separates it from the seasonal/upcoming tools. It never names a sibling such as get_seasonal_anime or get_anime_episodes, so the differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent how to use the filters ('optionally for a single weekday') and the paging defaults, but says nothing about when this tool is preferable to get_seasonal_anime, get_upcoming_season, or get_anime_episodes. Usage is implied by the resource rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds context about listing roles but does not disclose additional behavioral traits like pagination or performance. With annotations present, the description adds minimal extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Information is front-loaded: action, scope, and role types are immediately clear. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, no nested objects) and presence of an output schema, the description is sufficient. It explains the tool's purpose and relationship to a sibling. Minor gap: it doesn't describe the return structure, but output schema covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single required id parameter. The description adds meaning by specifying that the id is a MyAnimeList numeric ID (mal_id) and that it can be obtained from search_anime, which goes beyond the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists production staff of an anime by mal_id, specifying roles like director and composer. It explicitly distinguishes itself from the sibling tool get_anime_characters, which covers voice actors, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by indicating that the mal_id should come from search_anime and that this tool complements get_anime_characters. However, it does not explicitly state when not to use this tool or list alternative tools beyond the mentioned sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses a critical behavioral trait: transparent retry via official API when Tenrai is unavailable, and that in that case the scores field is entirely omitted. This adds value beyond the annotations (readOnlyHint, openWorldHint) by explaining a non-obvious data loss scenario.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence states purpose and output, the second provides fallback behavior. No unnecessary words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, output schema present, annotations covering safety), the description is complete. It covers purpose, input source, fallback behavior, and output variation. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the single parameter 'id'. The description adds value by instructing the user to obtain the mal_id from search_anime, which provides context for parameter acquisition. This exceeds the baseline of 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'watch-status counts and score distribution for an anime by mal_id'. It is specific and distinguishes from sibling tools like 'get_anime' which fetches basic info, and 'search_anime' which is used to obtain the mal_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the user to 'Get the mal_id from search_anime', providing context on how to obtain the required input. It also explains the fallback behavior when Tenrai is unavailable, including the omission of scores, which guides usage expectations. However, it does not explicitly state when not to use this tool or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, and the description does not contradict this. Beyond that, the description discloses the scope of results (multiple video categories), the per-item attributes returned, and the 'where available' caveat for count data. It does not discuss rate limits or authentication, but those are less critical for a read-only, single-ID lookup with a full output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler. The first sentence front-loads the core action and scope, the second differentiates from a sibling, and the third gives a necessary prerequisite. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one trivial parameter, a full input schema, an output schema, and read-only annotations, the description is complete for an agent to select and invoke the tool correctly. It even provides the upstream workflow for obtaining the required ID.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents id as a MyAnimeList numeric ID with bounds. The description adds the practical instruction to fetch that ID from search_anime, which is useful, but it does not need to restate parameter details already covered by the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List'), a specific resource ('an anime's promotional videos'), and enumerates concrete content types: PVs/trailers, episode preview clips, and music videos. It also explicitly contrasts itself with get_anime's single trailer field, so an agent can distinguish this tool from its closest sibling without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states when to prefer this tool: when the caller wants every promo rather than just the main one. It also directs the agent to search_anime to obtain the required mal_id, which is a direct prerequisite for invoking the tool correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint, openWorldHint) indicate safety and dynamic data. The description goes beyond by detailing the sfw/sfw_strict parameters' effect on appearance lists, noting the live filtering behavior and the distinction between sfw (allows Ecchi) and sfw_strict (excludes Ecchi). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary purpose, then efficiently covers parameter details in two additional sentences. Every sentence earns its place—no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not detail return values. It covers purpose, ID source, and parameter behavior thoroughly. For a straightforward lookup tool, this is complete and leaves no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters (100%), giving baseline 3. The description adds crucial context: sfw/sfw_strict filter the character's appearance lists, not the character itself. This additional explanation aids correct parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves full details for one character by mal_id, including bio, appearances, and voice actors. It also tells how to obtain the mal_id, distinguishing it from search_characters (which lists characters) and get_anime_characters (which lists characters for an anime). The verb 'Get' and resource 'character' are specific, making purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to obtain the mal_id from search_characters or get_anime_characters, providing clear guidance on prerequisite actions. It does not explicitly state when not to use, but for a simple lookup tool, this is sufficient and avoids confusion with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is read-only, and the description adds valuable behavioral nuance: sfw and sfw_strict filter entries rather than hiding the stack itself, entry order is curator-defined, and the tool has no official-API fallback. This goes well beyond what the annotations alone communicate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with the primary action stated first and supporting usage details following efficiently. Every sentence adds meaningful context, from entry ordering to chaining behavior to the absence of an API fallback.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only retrieval tool with a rich output schema. It tells the agent how to identify the stack, how to interpret recorded entry data, how sfw filtering behaves, and what dependency exists on Tenrai. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantic detail: the id is sourced from sibling stack-list tools, and sfw/sfw_strict operate on the entry list rather than hiding the stack. This reinforces and clarifies what the schema definitions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: fetch one MyAnimeList Interest Stack by mal_id, including entries in the curator's order with author_score and note. It also clearly distinguishes this from the sibling list-fetching tools by explaining how mal_id is obtained from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete guidance on how to obtain the mal_id from related interest-stack list tools and how each entry's mal_id can be chained into get_anime or get_manga. It does not explicitly enumerate when not to use this tool, but the usage context is clear and practical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and open-world nature, and the description adds the non-obvious operational facts: it returns stack metadata only (not entries), and it has no official-API fallback so Tenrai must be reachable. That availability constraint is exactly the kind of behavior an agent cannot infer from structured fields and would otherwise discover only by failing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the routing contrast to get_top_anime land in the first two sentences; the metadata-only caveat, per-title alternatives, and availability dependency follow in dependency order. The illustrative mood examples are compact and directly serve tool selection rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter browse tool with an output schema, the description covers what an agent still needs: what family of tool this belongs to, the return-shape boundary (metadata vs entries), the two-step path to actual entries, and the availability prerequisite. Nothing required for a correct call is missing or left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 11 parameters at 100% schema description coverage, the schema already documents search, pagination, sorting, and every filter enum in detail. The description only implies the browse-vs-search distinction ('Browse or search') and adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (browse/search) and a specific resource (MyAnimeList Interest Stacks), then defines what the resource actually is: user-curated themed anime/manga lists with per-entry curator scores and notes. This is clearly separable from get_top_anime, search_anime, and get_interest_stack without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger class ('taste- or mood-shaped requests' such as 'something melancholy' or 'cozy slice-of-life') plus the negative case where a ranking or genre filter is the wrong instrument. It also names three alternatives with the conditions selecting them: get_top_anime for 'what is best', get_interest_stack for a stack's entries, and get_anime_interest_stacks/get_manga_interest_stacks for one specific title.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data scope are covered. The description adds useful behavioral detail by saying results include MAL IDs and manga counts and by explaining the relationship to search_manga's magazines filter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences front-load the tool's function and then give the key usage instruction. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a read-only lookup/list tool: it explains what is returned, how to search, and how the result feeds another tool. Rich schema coverage and an output schema mean pagination and return structure need not be repeated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters, including pagination, sorting, and filtering behavior. The description only elaborates on `q`, but with full schema coverage that is sufficient to meet the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: list or search manga serialization magazines/publishers. It also names a concrete example, clarifies that results include MAL IDs and manga counts, and connects the tool to search_manga's magazines filter, so an agent can distinguish it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: use `q` to search by name, or look up an ID for use with search_manga's `magazines` filter. It does not explicitly state when not to use this tool, but the intended usage is clear and tied to a related sibling workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, it transparently discloses that sfw/sfw_strict only filter the related entries list, not the requested manga. It also reveals fallback behavior to the official MAL API under specific conditions, listing exactly which fields are omitted and that sfw flags are ignored there.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, with the primary purpose and return scope front-loaded. The longer third sentence is justified because it contains unique health fallback behavior that could not be inferred only from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a complete output schema, 100% parameter documentation, and detailed fallback behavior, an agent has enough to call this tool correctly. The only missing syntactic instructions (such as how to return fields) are covered by structured schemas.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all three parameters at 100% coverage, so the baseline is decent. The description adds meaningful enhancement by explaining how sfw/sfw_strict affect only the relations list, and how the fallback path ignores them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('get full details for one manga by mal_id') and itemizes the returned data: synopsis, score, genres, serialization, external links, and related entries. This clearly distinguishes the tool from search or character/recommendation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs the agent to obtain the mal_id from search_manga first, which is a critical workflow prerequisite. It lacks an explicit 'when not to use' statement, but the prerequisite and the detailed scope make the intended usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a read-only operation. The description adds useful detail about including roles and using mal_id, but it does not disclose deeper behavioral traits such as pagination, return size, or sorting. The description is consistent with 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences. The main purpose is front-loaded, and the ID-source instruction is exactly the kind of practical information that earns its place. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with an output schema, the description is complete. It specifies what the tool returns, what input is needed, and how to find that input. There is no major missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already explains that 'id' is a MyAnimeList numeric ID. The description adds value by clarifying that the ID is the manga's mal_id and pointing the agent to search_manga as the source for obtaining it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List the characters of a manga'), the resource ('manga'), and the kind of detail returned ('with their roles'). It does not explicitly compare against the sibling get_anime_characters, but the resource 'manga' differentiates the tool well enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent how to obtain the required ID ('Get the mal_id from search_manga'), which is clear and actionable. It does not explicitly discuss when not to use the tool or alternative tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and openWorld, so the safety profile is covered. The description goes further by disclosing that sfw/sfw_strict remove genres from the returned list itself and that sfw_strict additionally drops Ecchi — an effect on output content, not just on filtering, which is real added context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: purpose, downstream use, and filter side-effect — ordered by importance with zero filler. Nothing needs trimming and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema available and full parameter documentation, the description needn't explain return shapes. It covers purpose, routing, and filter consequences; the only minor omission is any mention of the `filter` parameter's role, which the schema handles well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the sfw/sfw_strict distinction and the filter enum, so the schema does the heavy lifting. The description's restatement of the sfw behavior is a useful summary but adds no syntax or format detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list manga genres/themes/demographics) plus what the output carries (MAL IDs). The 'manga' qualifier cleanly separates it from the sibling get_anime_genres without either schema being opened.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this to obtain numeric IDs that search_manga's `genres` parameter expects, naming the consuming sibling. It stops short of stating when not to use it (e.g. versus get_anime_genres), but the manga scoping makes the alternative obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the description rightly focuses on what they can't express: it returns stack metadata only (not entries) and has no official-API fallback, meaning it hard-fails if Tenrai is unreachable. That dependency/failure-mode disclosure is valuable; pagination and rate behavior are left to 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the purpose, then sibling comparison, then return-scope, then operational caveat. Nothing is repeated from the schema and every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and the description correctly limits itself to clarifying that only stack metadata comes back. It covers discovery path, follow-up tool, and the no-fallback constraint; the only gap is not hinting at the filtering/ordering options, which the schema handles fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the 10 filter/pagination parameters (sfw, sfw_strict, official, spoilers, challenges, sort/order_by) are documented in detail there. The description adds only that the id is a manga mal_id, which is mildly useful but not meaningfully beyond the schema — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the public MyAnimeList Interest Stacks that include a given manga') and immediately scopes the result to public stacks for one manga id. It explicitly distinguishes itself from get_anime_interest_stacks and get_interest_stack, so an agent can route without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete workflow guidance: get the mal_id from search_manga, and pass a stack's own mal_id to get_interest_stack for entries. No explicit 'when not to use' or alternative-listing condition, but the sibling relationships make the boundaries clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 non-obvious behavioral context: that sfw/sfw_strict filtering can sharply reduce results rather than being a no-op, which was 'verified live'. Pagination behavior is left to the schema, so not quite a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with verb, resource, and return fields in the first sentence, then routing guidance and the filtering caveat. Dense and nearly waste-free, though the sfw nuance sentence is lengthy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full output schema, 100% parameter coverage, and clear sibling routing, the description supplies everything an agent needs to call this correctly, including the id source and the filter caveat.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with rich per-parameter descriptions, so the baseline is 3. The description goes beyond by characterizing the real-world effect of sfw/sfw_strict filtering (sharp reduction, not necessarily zero), adding meaning the schema doesn't convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List recent news articles about a manga') plus the exact fields returned (headline, date, author, excerpt). It explicitly distinguishes itself from the get_news sibling for site-wide feeds, so an agent can pick it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Says it's for 'what's new / any announcements' questions, directs the agent to obtain the mal_id from search_manga, and names the alternative (get_news) with the condition that selects it. When-to-use, prerequisite sourcing, and exclusion are all explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare read-only and open-world behavior, while the description adds the 25-entry cap, no pagination, vote ordering, NSFW filtering of the recommendation list, and a detailed fallback path with changed entry count, possible ordering differences, and ignored sfw flags. This is substantial context 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and cap, then efficiently covers id sourcing, sibling alternatives, filtering, and fallback behavior. Every sentence carries operational information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup with annotations and an output schema, the description covers selection guidance, parameter sourcing, filtering semantics, result cap, and degraded-mode behavior. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sfw fields are already well documented, so baseline is 3. The description adds where to get mal_id, clarifies that filtering applies to the recommendation list itself, and notes that fallback ignores sfw/sfw_strict.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource, including scope, vote ordering, and the top-25 cap. It explicitly distinguishes itself from get_top_manga and get_recent_manga_recommendations, so an agent can select it confidently among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent to obtain mal_id from search_manga and names two alternatives with the conditions that select them. It also clarifies sfw filtering behavior and when the official API fallback applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint, so the description carries most of the burden and does well: it discloses the 1200-character truncation of review text, that `limit` caps the already-filtered page rather than triggering new fetches, and that Tenrai lists roughly 20 per page. It says nothing about auth needs, rate limits, or error behavior, so it is strong 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and identifier, then the pagination/cap mechanics, then the id-sourcing pointer. Dense with parenthetical asides, but each one (truncation length, chapters_read caveat, 20-per-page) is load-bearing rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema handling return shape and annotations covering safety, the description fills the remaining gaps: identifier source, pagination model, filter-before-cap ordering, and truncation. An agent has everything needed to call this correctly on the first try.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a 3 would be the floor, but the description adds real meaning the schema does not: filters and sort are applied before `limit` truncates the result, and `page` is tied to a ~20-per-page listing model. That ordering detail is exactly the kind of clarification a schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get user reviews for one manga') and scopes it by mal_id. It also distinguishes itself from the anime counterpart by explicitly noting `chapters_read` versus `episodes_watched` being anime-only, so an agent can separate it from get_anime_reviews without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent where to source the identifier ('Get the mal_id from search_manga') and clarifies the limit-versus-page relationship, which is the main misuse risk here. It stops short of naming get_anime_reviews as the alternative for anime, leaving that routing to inference from the chapters_read remark.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, immutable operation. The description adds critical behavioral context: 'no official-API fallback exists for this tool — it always needs Tenrai itself to be reachable.' This provides information beyond what annotations capture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the tool's purpose, and every part earns its place—no filler. It is efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter with full schema coverage and an output schema present, the description adequately covers what the tool returns, how to obtain the input, and a key behavioral distinction from a sibling tool. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining that the parameter is a mal_id and instructing the agent to get it from search_manga, which aids correct parameter selection beyond the schema's simple description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets read-status counts and score distribution for a manga by mal_id. It uses a specific verb and resource, and distinguishes itself from get_anime_statistics by mentioning the absence of an official-API fallback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to obtain the mal_id from search_manga, providing clear usage context. It also contrasts with get_anime_statistics regarding the fallback, but does not enumerate alternative tools or conditions for when not 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.

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 the authentication requirement ('Requires a MyAnimeList login'), which is operationally critical and not expressed in the annotations or schema. It also discloses the shape of each entry, which helps the agent decide it is the personal list rather than catalog data. That said, it says nothing about empty-list or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no waste, with the core purpose stated first and the auth precondition second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and filtering and pagination are fully specified in the schema. The description covers purpose and auth. It is slightly thin on how the list is scoped or paginated across a large collection, but it is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and all four parameters (sort, limit, offset, status) are documented in the schema, including enum semantics and sort ordering. The description adds no parameter-level guidance, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb plus resource ('Get the authenticated user's own anime list') with the scope qualifier 'authenticated user's own', which separates it from the public catalog siblings like get_anime and search_anime. It also enumerates the returned fields (status, score, progress). It does not name get_my_manga_list as the manga counterpart, so sibling differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Requires a MyAnimeList login' gives a useful precondition, which implies the tool is only for the logged-in user's private data. But there is no explicit statement of when to use it versus the read siblings or versus the mutation siblings update_my_anime_status and delete_my_anime_list_item. So usage must be inferred from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-dependency profile is covered. The description adds one genuinely useful behavioral fact beyond annotations: a MyAnimeList login is required. It says nothing about pagination behavior, empty-list handling, or result caps, so the value added is modest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste: the core action comes first, followed by the prerequisite. Nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 0 required params, full schema coverage, an output schema, and read-only annotations, the description only needs to establish identity and the auth precondition, which it does. A note on pagination/limit interaction with large lists would make it complete, but no essential information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both enums (sort, status) are documented inline, so the schema carries the parameter burden. The description's mention of 'status, score and progress' refers to returned fields rather than adding meaning about the parameters; it neither clarifies nor misleads.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the authenticated user's own manga list') and scopes it to the current user, which separates it from get_manga / search_manga. It does not explicitly name the sibling alternative it competes with (e.g., get_my_anime_list, get_manga), but the 'own/authenticated' qualifier makes the distinction inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'the authenticated user's own manga list' and the login prerequisite, so an agent can tell this is for personal list data rather than catalog lookup. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g., 'use search_manga for public catalog data').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, which covers the safe-read profile. The description adds genuinely new behavioral context beyond them: authentication is required and the data domain is restricted to anime because the upstream API exposes no manga statistics field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is returned, then the auth prerequisite, then the scope caveat. Nothing is redundant and every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary, and the tool takes no arguments. Given annotations already cover safety and openness, the description supplies exactly the missing pieces: auth requirement and the anime-only limitation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. 'Logged-in user' usefully confirms the identity is implicit (derived from session) rather than a caller-supplied argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: returns the logged-in user's MAL profile plus anime watch-status statistics. It is clearly distinguished from siblings get_my_anime_list (list entries) and get_anime_statistics (site-wide stats), and the anime-only scope is stated up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Supplies the key prerequisite ('Requires a MyAnimeList login') and a negative rule that saves wasted calls: there is no manga-stats counterpart, so the agent should not go hunting for one. It stops short of explicitly naming get_my_manga_list or login_mal as the fallback/routing options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 real behavioral context — that results are site-wide rather than entity-scoped, and that sfw/sfw_strict drop adult-content articles — but the sfw semantics largely duplicate the schema text and nothing is said about pagination limits or result-set size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: scope first, then filtering, then sibling routing, then the sfw caveat. No filler, and the most disambiguating information (site-wide vs entity-scoped) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return fields, and it correctly avoids that. It covers scope, routing and filtering, but leaves pagination behavior (page/limit defaults) entirely to the schema, a minor gap for a paginated list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented in detail (including the sfw vs sfw_strict nuance). The description's mention of q and tag restates what the schema says rather than adding new semantics; baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List recent MyAnimeList news articles") plus the fields returned and the site-wide scope. It explicitly contrasts with get_anime_news/get_manga_news, so an agent can distinguish it from siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: use q for keyword search, tag for topic filtering, and the sfw/sfw_strict pair for content filtering. It names the two sibling tools to use instead when the request is scoped to one anime or manga by mal_id, which is exactly the when-not guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals important non-obvious behaviors beyond the readOnlyHint: staff credits are capped at 200 with truncation flags, voice roles capped at 50 in arbitrary order, sfw filters apply only to the credit lists, and full_credits returns everything. This is exactly the kind of edge-case behavior an agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description packs a lot of useful nuance into a compact paragraph, but it is dense and somewhat sprawling rather than well-structured. The first sentence is a clear purpose statement, and the rest earns its place, though it could be tightened by using bullet points or shorter sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich output schema and high schema coverage, the description adequately covers the essential context: how to source the id, what the limits are, what filtering does, and how to get full results. There's no glaring gap for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all parameters with detailed descriptions, including edge-case notes for sfw vs sfw_strict, so the description adds little per-parameter meaning. It does add value by explaining the interaction of full_credits with the credits_truncated flag, but most parameter meaning is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (person by mal_id) and enumerates the distinct data returned: bio, staff credits, and voiced roles. It explicitly names the sibling search_people and get_character, making it easy for an agent to distinguish this tool from related lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Exactly when to use is stated: to fetch a single person's full details by mal_id, and the description explains how to obtain the mal_id from search_people or get_character. It also distinguishes get_character's voice_actors (with id) from get_anime_characters' (no id), giving clear alternatives and routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 genuine payload context beyond that: what this returns over the list tool (about text, official site and social media links), which tells the agent why to pay the extra call. It does not mention behavior for invalid or unknown IDs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both load-bearing: the first states what is returned and how it differs from the list tool, the second states the id prerequisite. Nothing is padded or repeated from the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no prose, and the description covers purpose, delta fields, and id provenance. The only gap for a lookup tool is error behavior on a nonexistent id, which is minor but absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single id parameter is already documented. The description adds meaning the schema cannot: that the value is a MyAnimeList producer/studio id and where to source it (get_producers), which reduces wrong-id errors.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Get full details for one anime producer/studio') and explicitly scopes it against the sibling list tool by noting it returns 'the fields get_producers already returns' plus extras. An agent can distinguish this detail endpoint from get_producers without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear precondition and call sequence: 'Obtain the mal_id from get_producers.' That routes the agent to the correct discovery tool first. It stops short of stating when-not to use it (e.g., for bulk listing), so it lands just under the explicit-alternatives bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a read-only, open-world operation, so the safety profile is covered. The description adds useful context that results are summary records with IDs and counts and that full profile data requires a follow-up call, but it does not discuss pagination limits, sort interactions, or open-world coverage caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly packed sentences front-load the purpose and end with the alternative detail tool. Every sentence carries routing or scope information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full schema, an output schema, and read-only/open-world annotations, the description supplies the remaining decision-critical context: what the list returns at a summary level and when to switch to get_producer. Minor omission of pagination behavior is covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, including the `sort`/`order_by` dependency and pagination limits. The description only calls out `q`, which repeats schema information rather than adding new syntax or filtering semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verb and resource ('List or search anime producers and studios') and adds the key payload detail ('MAL IDs and counts'). It explicitly contrasts this summary-list tool with get_producer for full profiles, so the agent can distinguish it from its closest sibling without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing: use `q` to search by name and use get_producer when a single studio's full profile is needed. It provides a positive alternative for the detail case but does not explicitly state exclusions or when not 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and open-world hints, but the description adds genuinely new behavioral context: the reduced field set and, importantly, that no official-API fallback exists so Tenrai reachability is required. This dependency/failure-mode disclosure is exactly the kind of value annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The output scope is front-loaded, then the follow-up pointer, then the reliability caveat — each clause carries distinct information. The exclusion list is dense but earns its place; only minor trimming would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return shape needn't be explained, and the description covers the two things an agent could not infer: the partial-field caveat with a routing action, and the lack of a fallback. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the two params (sfw, sfw_strict) are thoroughly documented in the schema, including their distinction. The description adds nothing further about parameters, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Return one random anime') and immediately scopes the output by listing excluded fields (relations/streaming/opening_themes/ending_themes/external). It differentiates itself from the get_anime sibling by routing callers there for those fields, so an agent can distinguish the two without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Good for discovery / suggestions' names the intended scenario, and the parenthetical explicitly says to call get_anime with the returned mal_id for missing fields, giving a concrete follow-up path. It stops short of stating when NOT to use it (e.g., when a specific title is already known), so it doesn't reach a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses two non-obvious behaviors: the response is deliberately trimmed of anime/manga/voice_actors fields, and there is no official-API fallback so Tenrai itself must be reachable. That availability caveat is exactly the kind of context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each earning its place: what you get, how to get the rest, when it's useful, and the failure caveat. The payload scope is front-loaded before the alternative routing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description doesn't need to enumerate return fields, yet it still flags which fields are absent. Combined with the fallback warning, an agent has everything needed to call it and to handle failure correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It stays silent on parameters, which is correct here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource ('Return one random character') and immediately delineates the payload's scope ('core details: no anime/manga/voice_actors'), which separates it from get_character and search_characters. An agent can pick this tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case ('discovery / trivia') and routes the agent to the correct alternative for full data ('call get_character with the returned mal_id'). It lacks an explicit exclusion statement (e.g. when not to use it), so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely new behavioral facts: the response is a partial object requiring a second call for full details, and there is no official-API fallback, so the tool fails when Tenrai is unreachable. That availability dependency is exactly the kind of context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is returned, then the follow-up path, then the availability constraint. No sentence is redundant and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained; the description covers the key operational caveats (partial payload, reachability requirement). It leaves the filter parameters entirely to the schema, which is acceptable given full coverage, but it could note the source pool the random pick is drawn from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the sfw vs sfw_strict distinction is fully explained in the schema, including defaults and the exact rating/genre thresholds. The description adds nothing about the two filter parameters, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Return one random manga') plus a scope qualifier (core details only, no relations/external). It also names the sibling to use for the missing data (get_manga), so an agent can distinguish it from get_manga, search_manga, and get_random_anime without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case ('Good for discovery / suggestions') and a concrete follow-up path: call get_manga with the returned mal_id for relations/external. It does not spell out a when-not condition (e.g. when a curated list or top list is preferable), so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint/openWorldHint, it discloses that the returned record omits anime/manga/voice_roles and that no official-API fallback exists, so Tenrai must be reachable. Those are meaningful operational constraints that annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: purpose and scope first, usage second, availability caveat last. Parenthetical detail is dense but purposeful, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter random lookup with an output schema and read-only/open-world annotations, the description supplies the needed purpose, scope limits, alternative route, and availability caveat. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

This is a zero-parameter tool, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly avoids inventing input semantics and uses its space for output scope and alternatives.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (return one random person) and enumerates the person types it covers. It explicitly differentiates from get_person by naming the fields it omits and the follow-up call to use for them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case ('Good for discovery / trivia') and an explicit alternative condition: if anime/manga/voice_roles are needed, call get_person with the returned mal_id. That is clear when-to-use and when-to-switch guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds a real availability constraint — no fallback data source, so failure means failure. It doesn't say anything about feed recency window, ordering, or pagination depth beyond the schema, so it's strong but not fully revealing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each carrying distinct load: what it returns, which sibling to use instead, and the availability caveat. Scope is established in the first clause with no preamble.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the schema fully documents the four optional params, so remaining burden is light. The description covers identity, disambiguation, and the one operational gotcha; only feed freshness/ordering is unstated, a minor gap for a browse tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the sfw/sfw_strict distinctions are documented in detail in the schema itself. The description adds no parameter-level meaning (e.g. how sfw interacts with the feed, or default page size), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.