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

Annotations already provide readOnly/openWorld/idempotent signals, so the burden is lower. The description adds genuinely useful behavioral detail beyond those annotations: loose/fuzzy name matching ('wano') and the canon-only scope. It does not describe ambiguity or no-match behavior, but the added context is meaningful.

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, zero filler. The output scope is front-loaded, and the loose-name usage note follows immediately. Every word contributes useful information.

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

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

For a single-parameter, read-only tool this is largely complete: purpose, accepted input behavior, and return topics are covered. Since there is no output schema, the description's field list serves as the return contract, but it does not spell out exact response shape or failure/ambiguous-match behavior.

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

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

With 100% schema description coverage, the baseline is 3. The description adds value by disclosing that loose, partial names are accepted and gives concrete examples ('wano', 'Enies Lobby') that the schema does not imply. This lifts it above baseline.

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

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

The description clearly names the resource (canon story arc) and the specific output fields it provides (saga, position, ranges, release years, neighboring arcs). It is slightly elliptical—no explicit verb—but the name and title make the action unambiguous, and it is easily distinguished from sibling tools like get_chapter and list_arcs.

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 note about accepting loose names is helpful input guidance, and it implies this tool is for looking up arcs by name. However, it never explicitly contrasts this with siblings like list_arcs, get_chapter, or search_wiki, nor does it state when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that the result includes both articles and subcategories, but it does not disclose pagination behavior, ordering, whether subcategories are direct-only, or behavior for nonexistent categories.

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 concise sentence with illustrative examples, and the core content type is front-loaded. It is efficient, though the lack of an explicit verb in the description means it relies partly on the title for action clarity.

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

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

For a simple listing tool with read-only annotations, the description is minimally adequate, but without an output schema it does not explain the exact return shape, pagination mechanics, or edge cases. The cursor and category prefix are only covered via the schema rather than in a way that gives the agent operational confidence.

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 67%: category and cursor are documented in the schema, while limit is not. The description itself adds no parameter-level meaning beyond illustrative category examples, so it does not compensate for the missing limit documentation.

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 title and description make clear this tool lists the articles and subcategories belonging to a category, with concrete examples. It does not explicitly contrast itself with sibling tools like get_page_categories, so it lacks the sharp sibling differentiation of the highest tier.

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?

There is no guidance on when to use this tool versus alternatives such as get_page_categories or search_wiki. The examples show plausible category names but do not state a use case, exclusions, or conditions that would route an agent to a different 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 readOnly, openWorld, and idempotent hints, which the description does not contradict. The description adds a behavioral constraint—'Blocked when past the spoiler limit'—which is not covered by annotations and provides valuable context about potential failures. This adds meaningful transparency beyond the structured metadata.

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

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

The description is a single, well-structured sentence that efficiently lists the returned fields and the spoiler limit condition. Every part earns its place with no fluff or redundant wording, and the key information 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?

For a simple read-only tool with one parameter, the description covers the returned data and a key behavioral edge case (spoiler limit). It does not discuss error handling or output format, but given the lack of an output schema and the simplicity of the operation, these omissions are minor. The description is complete enough for an agent to invoke it 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 has full coverage (100%) for the single parameter 'number', with a clear description 'Chapter number'. The tool description does not add any extra meaning beyond the schema, so the baseline score of 3 is appropriate—the schema does the heavy lifting and no additional context is required.

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 that the tool retrieves a manga chapter's details, listing specific attributes such as title, volume, release date, and more. While it doesn't explicitly differentiate from sibling tools like get_episode or get_arc, the focus on chapter-specific data makes its purpose clear and distinct.

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 no guidance on when to use this tool versus alternatives. It mentions a spoiler limit constraint but does not explain when to prefer get_chapter over get_episode or get_arc, nor does it state any exclusions or prerequisites. This is a significant gap given the presence of similar sibling tools.

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, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral context beyond annotations: it discloses the blocking condition when chapters exceed the spoiler limit and clarifies that the chapters field is empty for filler episodes. This enriches the agent's understanding of potential failures and return content without contradicting the annotations.

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

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

The description is two sentences with zero waste. The first sentence front-loads the full list of returned fields, and the second succinctly states the blocking condition. Every word contributes value, and the structure is easy to scan.

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

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

Given the tool's simplicity (one parameter, no output schema, annotations covering safety), the description is largely complete. It covers what is returned, the filler behavior, and the spoiler blocking. Minor gaps include absence of error handling (e.g., nonexistent episode) and explicit scope (which anime), but these are not critical given the sibling context and typical usage. Overall, an agent can correctly invoke the 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% for the single parameter 'number' (described as 'Episode number' with a minimum of 1). The tool description adds no additional meaning about the parameter beyond what the schema already provides. With full schema coverage, the baseline score of 3 is appropriate; the description does not need to compensate.

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 what the tool returns: episode title, air date, season, opening song, adapted chapters, and a summary. It also names a specific constraint (blocking on spoiler limit) that distinguishes it from sibling tools like get_chapter and get_arc. The verb is implied ('retrieves'), but the resource and its content are explicit, making the 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 provides context about a blocking condition (spoiler limit) but does not explicitly state when to use this tool versus alternatives. It doesn't say 'use this for episode details, use get_chapter for chapter details,' leaving the agent to infer the distinction from the tool name and sibling list. The guidance is adequate but not 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 already establish read-only, idempotent behavior. The description adds useful return-shape behavior: fields outside the main block are prefixed with their group (e.g., 'Devil Fruit – Type'), which helps an agent interpret results. It does not discuss missing-infobox behavior, but that is a minor gap given 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?

The description is only three sentences, all of which carry useful information: the core output format, per-type field examples, and the group-prefix convention. It is front-loaded with the main purpose and has 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 single-parameter read-only tool with no output schema, the description covers the output structure and field categories reasonably well. It does not specify behavior for articles without infoboxes or error/edge cases, and lacks explicit guidance relative to sibling tools, so it is adequate but not complete.

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

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

The single parameter title is fully documented by the schema (100% coverage), including an example and redirect behavior. The description adds no further parameter-specific semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the action and resource: retrieving an article's infobox as label/value pairs, with concrete field examples for characters and other entity types. It does not explicitly name sibling tools or contrast itself with get_page/get_page_sections, but the infobox focus makes 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?

Usage is implied rather than stated: the field lists tell the agent what data is available for characters, Devil Fruits, arcs, ships, and places, so when an infobox is needed this tool is the natural choice. It does not explicitly say when to prefer get_page, search_wiki, or other siblings, nor when not to call it.

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 signal read-only and idempotent behavior. The description adds valuable behavioral context: removal of references, navigation boxes, and infobox, plus the spoiler-limit behavior that removes later-arc sections. No contradiction with annotations.

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

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

Three sentences with no filler. The main purpose is front-loaded, followed by an alternative tool and usage notes. 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?

For a read-only tool with no output schema, the description covers purpose, behavior, spoiler handling, and usage hints. It could mention get_page_sections explicitly for discovering section headings, but the schema does that. Overall it provides enough for an agent to invoke 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 description adds meaning for the `section` parameter by explaining it is for long articles and that '0' is the intro, going beyond the schema. It also ties section behavior to spoiler limits. However, it does not add anything about `max_chars`, and schema coverage is only 67%, leaving some burden unmet.

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 a specific verb and resource: 'Readable text of an article.' It also explicitly names get_infobox as the tool to use for the infobox, which differentiates it from a key sibling. This makes the tool's scope 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?

It gives explicit guidance to use get_infobox for the infobox and to pass `section` for long articles. However, it does not contrast with other read siblings like get_chapter, get_episode, or get_arc, so the when-not-to-use guidance is incomplete.

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, openWorldHint, and idempotentHint, covering the safety and idempotency profile. The description adds little beyond the basic action—it doesn't discuss redirect handling, pagination, or output format. With annotations covering the main traits, the description provides marginal extra value, warranting a baseline score.

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, front-loaded sentence that immediately states what the tool does and gives a concrete example of its use. There is no wasted words, and the key information is presented first. It is appropriately concise for a simple tool.

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

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

For a read-only tool with one well-documented parameter and annotations covering safety, the description is adequate. It explains the value proposition (quick view of categories) without needing to detail output format since no output schema exists. Minor gaps like explicit mention of redirects are already handled in the schema, making it complete enough.

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 fully documents the single 'title' parameter with an example and redirect behavior, achieving 100% coverage. The description does not add any parameter-specific detail, so it relies entirely on the schema. Baseline 3 is appropriate since the schema carries the full burden.

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 lists an article's categories, with a specific example of what those categories reveal (crews, Devil Fruit type, etc.). It is a specific verb+resource and distinguishes itself from siblings like get_category_members, though it doesn't name them explicitly. The title and description together make the purpose unambiguous.

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

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

The description implies usage context ('a quick way to see a character's...'), suggesting it's for lightweight category exploration. However, it does not explicitly mention when to use this tool over alternatives such as get_infobox or get_category_members, nor does it state any exclusions. Usage guidance is implied but not 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 already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate safety. It adds the integration behavior that the returned indexes are directly consumed by get_page, which is useful context. No contradiction; edge cases like missing articles are not discussed, but the annotation bar lowers the burden.

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?

A single, front-loaded sentence conveys output type and downstream use with no filler. Every word carries meaning and it explicitly references the relevant sibling tool.

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 simple parameter, no output schema, and safety annotations, the description is nearly sufficient. It tells the agent what it returns and how the indexes connect to get_page, though it could be more explicit about the response shape (e.g., top-level headings only).

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 only parameter, title, is fully documented in the schema including an example and redirect-following behavior, so schema coverage is 100%. The description adds no additional parameter semantics beyond implying the article is identified by title, so 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 identifies the tool's output—section headings with indexes—and differentiates it from sibling tools by linking to get_page's 'section' parameter. The title supplies the verb 'List,' so an agent immediately knows this returns a list of headings rather than page content, infobox data, or categories.

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 phrase 'indexes usable as get_page's `section`' tells the agent the natural use case: fetch sections before requesting a specific page section. It does not name exclusions or compare against siblings like list_subpages, so it stops short of explicit when-not-to-use guidance.

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

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

Annotations already communicate read-only, idempotent, and open-world behavior. The description goes beyond them by clarifying the null-when-unset behavior and the exact meaning of 'spoiler limit,' which is essential since there is no output schema. No side effects or auth caveats are mentioned, but none are needed for this tool.

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?

A single sentence provides the full semantic definition with no filler. The key value ('last chapter the user has read') is front-loaded, and the null case is included in the same breath.

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 zero parameters and a clear, self-contained definition of the return value, the description is complete enough for an agent to invoke and interpret the result correctly. The absence of an output schema is compensated by directly stating the possible outcomes.

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

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

The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. This earns the baseline of 4 for parameterless tools.

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 unambiguously defines the resource and its value: the current spoiler limit as the last chapter the user has read, with null when unset. This also distinguishes it from the sibling set_spoiler_limit, which mutates rather than retrieves.

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

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

The description implies this is the read-side counterpart to set_spoiler_limit, but it never explicitly states when to use this tool instead of an alternative. For a simple parameterless getter this is acceptable, but the guidance is left to inference 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that output is ordered, grouped by saga, restricted to canon arcs, and omits arcs beyond the spoiler limit. It also explains the optional filtering behavior, giving an agent important behavioral context not present in structured annotations.

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

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

Three economical sentences front-load the primary list behavior, add a secondary lookup mode, and close with the spoiler-limit caveat. No word is wasted 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?

Given one optional parameter, no output schema, and a straightforward list operation, the description covers the output shape (ordered, grouped by saga, chapter/episode ranges), the filtering behavior, and spoiler-limit interaction. Minor details like exact field names or empty-result behavior are not spelled out, but the description is strong enough for an agent to call it 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 fully documents `chapter` as 'Only return the arc containing this chapter' (100% coverage). The description restates this as 'answers which arc is chapter N in?' and adds use-case framing, but provides no additional semantic details about types, defaults, or edge cases, so it earns the baseline 3.

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 the resource ('canon story arcs'), the action ('list ... in order'), the grouping ('by saga'), and the output detail ('chapter and episode ranges'), and it also calls out the chapter-based lookup mode. This clearly distinguishes it from sibling tools like get_arc and get_chapter.

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 establishes two direct use cases—get the full ordered arc list, or resolve a chapter to its containing arc via the `chapter` parameter. However, it never names alternatives such as get_arc or get_episode, nor does it say when not to use this tool, so it falls short of the explicit routing 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 readOnly, openWorld, and idempotent, covering the safety profile. The description adds context about tab naming conventions but no additional behavioral constraints or edge cases. It is consistent with annotations, so a mid-range score is appropriate.

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

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

The description is two sentences: the first states the core purpose, the second provides illustrative examples and a usage pointer. No wasted words, and the most important information 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?

For a one-parameter read-only list tool, the description covers what it does and how to proceed. It doesn't specify the exact return format, but that is implied by the tool name and the workflow. Given the simplicity, it is sufficiently complete.

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

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

The schema fully documents the single 'title' parameter with an example and redirect behavior, so the description need not add more. Since schema coverage is 100%, this meets the baseline without requiring extra 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 states a specific verb 'list' and resource 'subpages of an article', and provides concrete examples of typical subpage names. It clearly distinguishes this from reading a page (get_page), making the tool's role 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?

It explicitly suggests a workflow: find subpages here, then read one with get_page. While it doesn't explicitly exclude other tools like get_page_sections, the guidance is sufficient for a simple list operation and points to the natural next step.

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, openWorldHint, and idempotentHint, covering the safety profile. The description adds behavioral context beyond those annotations by explaining that large articles are split into subpages and those subpages appear in search results, which is useful for anticipating result types.

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

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

Two sentences, no filler, and the core purpose is front-loaded. The subpage detail earns its place because it materially affects what results will look like.

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 adequate for invoking the tool with query and limit, and the subpage behavior is a useful hint about results. However, there is no output schema and the description does not state what the returned results contain (e.g., article titles, snippets, pagination), leaving some ambiguity for an agent interpreting the response.

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 documents query with examples and shows limit's type/default/min/max, but only 50% of parameters have semantic descriptions. The description adds no parameter-level meaning, neither explaining how query is matched nor describing what limit controls in terms of result count.

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 ('search') and resource ('One Piece Wiki articles'), and explicitly notes that full-text search includes subpages. This distinguishes it from sibling tools like get_page or get_page_sections, which retrieve specific pages rather than performing full-text search.

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

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

The description implies usage: an agent should use this tool when it needs to find articles by free-text terms, as opposed to retrieving a known page. However, it never explicitly names alternative tools or states when not to use it, leaving the routing decision to inference.

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 mutation (readOnlyHint=false) and possible outside effects (openWorldHint=true). The description adds specific behavioral detail beyond that: chapters, episodes, and arcs past the limit are withheld, and article sections about later arcs are removed. It also discloses the off-switch behavior, enriching the agent's mental model.

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 each earning its place: main action, consequence/side effect, and usage trigger with examples. No filler or repetition. The structure front-loads the most important information.

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

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

For a simple 2-parameter tool with no output schema, annotations covering idempotency/open-world, and a sibling getter, the description is complete. It covers purpose, side effects, when to invoke, and how to disable. The schema itself documents each parameter, so no critical 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 coverage is 100%, so baseline is 3. The description adds value by explaining the no-chapter-to-turn-off behavior and giving an arc example that shows how the parameter maps to a chapter cutoff. This goes beyond the schema's field-level descriptions and clarifies real usage.

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

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

Description opens with a specific verb and resource: 'Set the last manga chapter the user has read.' It goes beyond a bare statement by explaining the consequence (chapters/episodes/arcs past it are withheld) and clearly distinguishes itself from the sibling get_spoiler_limit, which reads rather than sets.

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 an explicit usage trigger: 'Use this whenever the user says how far they are' with concrete examples (chapter 900, Enies Lobby). It also explains how to turn the limit off. It does not mention alternatives or exclusions, but no alternative setter exists among siblings, so the guidance is clear and actionable.

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