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

With destructiveHint=true and idempotentHint=false already declared, the description adds substantial context beyond annotations: non-overwrite semantics, that omitted fields are preserved, that score follows the account's format, and the full preview/confirmation handshake including 'Never fabricate approval' on confirmation_id. It also reconciles the destructive hint with the direct-execution path for ordinary single-entry adds.

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 core constraint, then the execution/confirmation model, then the dry_run escape hatch. Dense and largely waste-free, though the dry_run sentence slightly overlaps the schema's own dry_run description.

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 8-parameter destructive write tool with no output schema, the definition covers safety, confirmation, and field-preservation behavior. It stops short of stating auth requirements or what happens when neither media_id nor a unique title resolution is supplied beyond what the schema already notes.

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 63%, and the description compensates on the highest-risk fields: status is mandatory, score uses the account's format (beyond the raw 0-100 bound in the schema), and confirmed/confirmation_id are bound to the described preview flow. Remaining params (progress, media_id, title) are left to schema descriptions, which do cover 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?

States a specific verb and resource ('Add anime') and immediately narrows scope with 'only if no entry exists' and 'Existing entries are never overwritten by add.' That negative clause implicitly draws the boundary against update_list_entry/update_anime_status, so an agent can tell add from update 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 when-to-use mechanics: explicit status required, dry_run:true to preview, and the confirm-then-repeat-with-confirmation_id loop for destructive/bulk changes. It never names the specific sibling to use instead when an entry already exists, so the alternative is inferred 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?

Adds substantial behavior beyond the destructiveHint=true annotation: never overwrites existing entries, preview/confirmation_id/confirmed flow, and dry_run previewing. The claim that ordinary single-entry changes execute directly is slightly in tension with a blanket destructive hint, and there is mild redundancy with the schema's confirmed/confirmation_id descriptions, keeping it below 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 the core constraint (add only, no overwrite), then the safety flow. Dense but each sentence carries operational meaning; the confirmation sentences are somewhat long and restate schema parameter descriptions.

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?

No output schema, 8 parameters, and a mutation of a user's list — the description covers the safety-critical pieces (preview, confirmation, dry_run, non-overwrite, required status). It stops short of describing what a preview result looks like or what the title-resolution failure path returns beyond the schema note.

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 63% schema coverage, the description compensates by stating that status is mandatory, that score follows the account's format, and that omitted fields are preserved (an important semantic not in the schema). confirmed/confirmation_id/dry_run guidance duplicates schema text rather than adding to 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?

"Add verified manga only if no entry exists" names a specific verb and resource, and the 'no entry exists' clause plus 'Existing entries are never overwritten by add' clearly delineates it from add_anime_to_list and update_list_entry. 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 clear when-to-use conditions (verified manga, no existing entry, status required) and an explicit branch for destructive/bulk changes with a confirm-then-retry procedure. It does not explicitly name update_list_entry as the alternative for existing entries, so routing is implied 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?

Goes well beyond the destructiveHint=true annotation: discloses pre-write validation, post-approval revalidation, sequential writes, stop-at-first-failure, per-entry completed/failed/skipped reporting, and explicitly states it is 'Not an atomic transaction' — a critical partial-failure property an agent could not infer otherwise.

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?

Six dense sentences, front-loaded with what is updated and followed by execution semantics and the approval flow. Every sentence carries information, though the confirmation/dry_run guidance is packed tightly enough to warrant a single careful read.

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 destructive, no-output-schema bulk write, the description covers everything an agent needs: entry cap, validation ordering, non-atomicity, failure reporting shape ('completed/failed/skipped'), the approval gate, and the preview escape hatch. Return-value ambiguity is resolved inline despite the missing output 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 coverage is 75%, so most parameter meaning is already structured; the description still adds real value by explaining the preview→confirmation_id→confirmed:true handshake and the PATCH-like rule that 'Omitted fields are preserved.' It does not elaborate on the entries array contents beyond media ID/type/patch, which the schema already covers.

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 with explicit scope: 'Update 1–5 existing entries, each with explicit media ID, media type and requested patch.' The '1–5' bound and 'bulk' framing separate it from single-entry siblings like update_list_entry, though no sibling is named explicitly.

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 routing: ordinary single-entry changes execute directly, destructive/bulk changes return a preview requiring user confirmation and a repeat call with confirmation_id and confirmed:true, and dry_run previews anything. It never names sibling tools as alternatives and 'executes ordinary requested single-entry changes directly' is ambiguous against update_list_entry, which keeps it 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 establish readOnly, idempotent, openWorld, non-destructive, so the safety bar is low. The description adds real behavioral context beyond that: that the response bundles in the user's existing list entry and community recommendations, and a caution about treating recommendations as candidates rather than facts.

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, front-loaded with the core action and the return contents, followed by the recommendation caveat. The field list is slightly dense but nothing is 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?

With no output schema, the description does the work of naming what comes back (episodes, genres, description, entry, recommendations). The main omission is error behavior for an invalid or unknown media_id, which matters for a verify-style lookup.

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?

Only one parameter and 0% schema description coverage, so the description must carry the load. It does identify media_id as an AniList anime ID, which is the key semantic, but adds no format, range, or validity detail (e.g., positive integer, what happens on an unknown ID).

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 (verify/read) and resource (an AnimeList anime), and enumerates the fields returned: episodes, genres, description, existing entry, recommendations. It implicitly distinguishes itself from search_anime by framing the input as an existing AniList ID to verify, but never names the sibling explicitly.

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 'Verify an AniList anime ID' implies you must already have an ID (i.e., use search_anime first), but this is left to inference. The one explicit guideline, that recommendations are candidates and library membership should be checked first, is genuinely useful but only covers post-call handling, not when to choose 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 this a safe, idempotent, non-destructive read with openWorldHint, so the description's job is lighter. It adds genuinely useful behavioral context — that the result set is split into separate CURRENT and REPEATING pages, each with its own pageInfo, and that both must be followed. It does not disclose auth requirements or maximum page limits, keeping this at an adequate rather than rich level.

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 with no waste; the pagination caveat and the include_repeating instruction are front-loaded after the one-line purpose. Every sentence adds decision-relevant 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 3-parameter read tool with no output schema, the description covers the critical operating detail — split pagination with two pageInfo cursors — that an agent would otherwise get wrong. The main remaining gap is silent page/per_page parameters, but overall an agent could call this correctly from the description plus 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 0%, so the description carries the burden, and it does explain the semantically tricky parameter (include_repeating) with its default-off behavior and what it adds. However, page and per_page are never mentioned, and their non-obvious constraints (per_page caps at 50, page at 10000) go undiscussed. Partial compensation only.

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: 'Read a paginated anime list' scoped to the CURRENT watching status, which distinguishes it from the broader get_my_anime_list sibling. It doesn't explicitly name that sibling as the alternative, but the status scoping is clear enough for an agent to tell the tools apart.

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 status scoping: use this when you want currently-watching entries, not completed/planned. The include_repeating flag is given a condition ('to also return the separate REPEATING page for rewatches'), but the description never names an explicit alternative for other statuses, so the when-not guidance is left 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 declare readOnly, idempotent, non-destructive and openWorld, so the description's added value is in disclosing the payload: chapter/volume counts, genres, the caller's existing entry, and community recommendations — the last two hint at user-scoped data and external aggregation. It omits what happens for an unknown/private ID, which matters given the word "verify".

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?

One front-loaded sentence with a semicolon-delimited payload list; every clause carries information an agent can act on, and there is no boilerplate.

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 no output schema, the description is the only signal about return contents and it does list them adequately. However, for an openWorld read that can fail on invalid IDs or touch user-scoped data, it gives no error or auth context, 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 has 0% schema description coverage, so the description must carry it, and "AniList manga ID" does constrain the opaque integer to a specific ID namespace. It does not say where to source that ID (search_manga) or that it must be a manga rather than an anime ID, leaving a small but real gap.

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: it names the AniList manga ID and enumerates what is read (chapter/volume counts, genres, existing entry, recommendations). That separates it from get_anime_details and the list-mutation siblings. It falls short of 5 only because sibling differentiation is implicit rather than stated.

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?

"Verify an AniList manga ID" implies the use case (resolving/validating an ID before calling add_manga_to_list or update_manga_progress), but the agent must infer that. There is no explicit when-to-use, no statement that search_manga should be used first to obtain an ID, and no exclusion of any 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the account's scale is not necessarily 10-point, so callers must not hardcode. It says nothing about what happens if no AniList account is connected (error vs null), which is the main unknown for an auth-adjacent 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?

Two short sentences, front-loaded with what is returned, then the usage constraint. Every clause carries information; nothing is 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?

With no output schema, the description usefully enumerates the four returned fields, which is the right burden to carry. The only gap is failure behavior when no owner is connected, though for a trivial zero-argument read that is a minor omission.

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 there is nothing for the description to disambiguate and the 4 baseline applies. No parameter guidance is needed or missing.

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 ('Get') plus resource ('the connected owner... AniList profile') and it enumerates exactly what comes back: owner, AniList user ID, profile URL, scoreFormat. It doesn't name or contrast a sibling (e.g. get_my_anime_statistics), so the differentiation is only 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?

Gives a concrete trigger — read this before any score change — and an explicit warning not to assume a 10-point scale, which is real decision guidance. It stops short of naming the alternative tools (update_anime_score / update_manga_score) it gates.

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 handle safety constraints like readOnlyHint, destructiveHint, and idempotency. The description adds critical behavioral context by defining the required iterative workflow for full data retrieval, thereby significantly enhancing utility 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 two sentences are perfectly structured, with the first defining the core function and the second detailing the critical operational behavior (pagination). Every part of the definition is necessary and efficient.

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 lack of an output schema, the description is highly complete. It not only tells the agent what data it will receive but also how to manage the entire dataset using the pagination mechanism.

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 0%, requiring the description to carry the weight. It specifies the high-value data fields returned (status, score, episodes, genres), which informs the agent about the semantics of the data retrieved via the parameters, meeting the minimum viable standard for low 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 explicitly states the function (Read one page of the owner anime library), the specific data contained (status, score, episodes, genres, and notes), and distinguishes this list retrieval from detailed lookup tools like get_anime_details.

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 provides a complete operational guideline by instructing the agent to follow the pagination mechanism ('Follow pageInfo.hasNextPage until false'). This defines the intended usage pattern for comprehensive library analysis, which is crucial for an iterative list-fetching 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?

The annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds the data domains and recommendation-oriented purpose, but it does not clarify return structure, aggregation scope, or edge cases; with rich annotations, this is useful but still moderate transparency.

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 written sentences: the first front-loads what data is read, and the second explains the intended combined use. There is no filler or repetition.

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 zero-parameter, read-only statistics tool with no output schema, the description is largely complete: it enumerates the stat categories and states how to use them with the library. It could still specify whether statistics cover all-time or all statuses, but the core operational context is present.

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, so the baseline is 4. The description does not need to explain input semantics, and it correctly focuses on what the tool reads and how to combine it with another tool.

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 ('Read') and names the exact aggregate data returned: totals, mean score, formats, statuses, genres, and tags. It implicitly distinguishes itself from list-oriented siblings by emphasizing statistics and later saying to combine with the anime library pages, though it does not name an alternative explicitly.

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 use case: infer preferences and combine with all pages of the anime library to recommend unseen titles. This helps an agent understand it is not a replacement for the library listing tool, but it stops short of explicit when-not-to-use guidance or naming the sibling to use for entries.

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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context by saying it returns one page and that callers should follow hasNextPage, and it lists returned fields such as chapter/volume progress, scores, and genres. It does not cover auth or rate limits, but the annotation coverage 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?

Two concise sentences with no wasted language. The core purpose is front-loaded, and the pagination instruction follows immediately.

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 no output schema, the description helpfully names returned fields and pagination behavior. However, it leaves the undocumented status and per_page parameters unexplained, so it is only minimally complete for a tool with three parameters at 0% schema coverage.

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 0%, so the description must compensate, but it only hints at the page parameter through 'one page' and 'hasNextPage.' It does not explain the status filter or its enum values, nor per_page, its default, or its maximum.

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: reading one page of the owner's manga library, including progress, scores, and genres. This clearly distinguishes it from search_manga and from get_my_anime_list, though it does not explicitly name any sibling tool.

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 'owner manga library' and the pagination instruction 'Follow hasNextPage for the complete library.' However, there is no explicit guidance on when to choose this over search_manga or get_manga_details, nor any stated exclusions.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description goes meaningfully beyond them: it names exactly what is destroyed (score, progress, notes), confirms the media record survives, and documents the mandatory preview/confirmation handshake and the fact that omitted fields are preserved. That is the extra context an agent needs before invoking a destructive 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?

Five short sentences, front-loaded with the destructive scope before the procedural detail. Every sentence carries information, though the "ordinary requested single-entry changes" clause adds a slightly confusing distinction rather than 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 6-parameter destructive tool with rich annotations and no output schema, the description covers impact, approval flow and preview mechanics well. The one residual gap is that it never resolves whether a single-entry delete counts as "ordinary" (executed directly) or "destructive" (preview required), leaving the agent to infer when confirmation is mandatory.

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 already 83%, so the bar is a baseline 3; the description nonetheless explains the dry_run preview behavior and the confirmed/confirmation_id retry protocol, which the schema only labels tersely. It does not clarify the title-vs-media_id selection path, but the schema covers that inline.

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 ("Permanently delete the connected owner list entry") and immediately scopes what is not affected ("the anime/manga itself is not deleted"). This clearly separates it from update_list_entry, update_anime_score and the other mutation 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?

Gives a concrete workflow: always require explicit human approval of the exact preview, use dry_run:true to preview, and re-issue with confirmation_id plus confirmed:true after approval. The only weakness is ambiguity between "executes ordinary requested single-entry changes directly" and "destructive changes return a preview" — a single-entry removal arguably falls in both buckets, and no sibling alternative is named for bulk removals.

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 read-only, idempotent, open-world, non-destructive behavior. Beyond that, the description adds useful context about returning verified AniList IDs and current list entries, and warns against silently choosing ambiguous titles; pagination and rate-limit behavior remain unmentioned.

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 wasted language: purpose first, return values second, and recommendation workflow third. The most important routing and ambiguity constraints 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?

The description covers the tool's purpose, return content at a high level, and recommendation workflow, but with eight parameters at 0% schema coverage and no output schema, more detail on pagination, adult-content filtering, and return shape would be needed for full completeness.

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 0%, so the description must carry parameter meaning. It usefully maps title, genre, year, popularity, and exclusion of watched/current/repeating/dropped titles to relevant parameters, but it leaves page, per_page, include_adult, and sort enum values unexplained.

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, names the search modes (title, genre, year, popularity), and clarifies that results are candidate anime rather than detail records. This distinguishes it from sibling tools like get_anime_details and search_manga without requiring schema inspection.

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 recommendation workflow: analyze the complete library first, then exclude watched/current/repeating/dropped titles. It does not explicitly name alternatives such as get_anime_details or search_manga, but the usage context is strong enough for an agent to know when this search tool is appropriate.

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, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds return-field information and a disambiguation instruction, which is genuine added value. It stays silent on pagination behavior (page/per_page defaults), adult-content filtering, and result-size limits, so it is helpful but not rich.

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 capability, followed by return contents and the one workflow rule. No filler and nothing repeated from the name or 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?

No output schema exists, and the description does cover the key return fields, which is the most important gap filled. But with 8 undocumented parameters, no required-parameter guidance, and no mention of pagination or adult filtering, an agent still has to guess at invocation details.

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 0% across 8 parameters, so the description must carry the burden. It only surfaces genre, year and an implied query string; sort, page, per_page, include_adult and exclude_media_ids are entirely unexplained, including their defaults and 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 a specific verb and resource ('Search manga candidates') and names the two modes: query search vs browsing by genre/year. It also discloses what comes back (IDs, chapter/volume counts, current list entries). It does not explicitly distinguish itself from get_manga_details, but 'candidates' implies the pre-detail discovery step.

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 line 'Present ambiguous matches for the user to choose' gives a useful workflow rule, and 'browse by genre/year' implies when the filter mode applies. However, there is no explicit guidance on when to call this vs get_manga_details, nor on combining query with genre/year, nor on when to page through results.

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?

Goes well past the annotations (destructiveHint=true, idempotentHint=false) by explaining the two-phase write: ordinary single-entry changes execute directly, destructive/bulk changes return a preview that requires confirmation_id plus confirmed:true. It also discloses that omitted fields are preserved and that totals are validated, which is exactly the mutation-safety context annotations can't 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?

Seven short, front-loaded sentences that each carry information. Minor redundancy between the preview sentence and 'Set dry_run:true to preview any change', and the 'Destructive/bulk' phrasing is slightly odd for a single-entry tool when bulk_update_entries is a sibling.

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 6-param mutation with no output schema, the description covers the execution model, the confirmation gate, dry-run, and field preservation — everything needed to call it safely. Only the failure mode when progress exceeds known totals is left implicit.

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 83%, so most params are already documented, but the undocumented `progress` is compensated by 'Set absolute episodes watched' and 'Checks known totals'. The dry_run and confirmation flow is reinforced in prose beyond the schema descriptions; only the interaction between progress and episode totals (error vs clamp) remains unstated.

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 ('Set absolute episodes watched on an existing anime entry') and pins down the key semantic — absolute set, not increment — which is exactly what distinguishes it from update_manga_progress and bulk_update_entries in the sibling list. An agent can route to 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?

Explicitly excludes other field changes ('Does not request status, score, dates or other field changes'), which implicitly routes to update_anime_score/update_anime_status, and lays out the preview→confirm→repeat workflow. It stops short of naming those siblings explicitly, so the routing is inferential 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 destructive, non-idempotent, open-world; the description adds the important operational detail they cannot: no automatic score conversion between formats, zero clears the score, omitted fields are preserved, and the preview-then-confirm handshake for destructive writes. That is the extra context a mutating tool needs.

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 dense sentences, front-loaded with the score-format rule that an agent most needs. Slightly information-packed (format scales, confirmation flow, dry_run, field preservation in one block) but nothing is redundant.

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 destructive single-field mutation with no output schema and 6 parameters, the description covers value semantics, preview/confirm workflow, and preservation of untouched fields. It stops short of stating auth/scope requirements or what the preview response contains.

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 83%, so most parameters are already documented, but the required 'score' field has no schema description and the prose compensates with scale/format semantics and zero-clears behavior. It does not explain how 'title' resolution interacts with 'media_id' beyond what the schema already states.

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?

Names a specific verb and resource ('Set an existing anime entry score') and pins down the value semantics (scoreFormat scales, zero clears). It does not explicitly route away from the generic sibling update_list_entry or toward update_manga_score, but the anime-score scope is unambiguous from the sentence itself.

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 clear operating rule: ordinary single-entry changes execute directly, destructive/bulk changes return a preview that must be confirmed and repeated with confirmation_id/confirmed:true, and dry_run previews anything. What is missing is explicit guidance on when to prefer this over update_anime_progress, update_anime_status, or update_list_entry.

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 destructiveHint=true and idempotentHint=false, yet the description adds substantial context the annotations cannot: the preview-then-confirm protocol, 'Never fabricate approval' semantics, dry_run behavior, and 'Omitted fields are preserved'. Minor tension remains: annotations flag every call as destructive while the description says ordinary single-entry changes execute directly, so the agent may be unsure whether a simple status change also needs the confirm round-trip.

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 core action and the constraint that progress is untouched, then the confirm workflow. The six-value enum recital duplicates the schema enum and is the one sentence that doesn't fully earn its space.

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?

Covers the hard parts for a 6-parameter mutation tool: preview/confirmation, dry-run, and field preservation, with no output schema to explain. It still doesn't describe what the success response or the preview payload contains, leaving the agent to guess what it hands back after the confirmed retry.

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 83%, so the schema already explains title resolution, media_id, dry_run, confirmed and confirmation_id; the description mainly repeats the status enum and adds the 'category' meaning (status only, no progress). The valuable addition is linking confirmation_id to 'this exact write preview', but that workflow is largely for the bulk path rather than the required status parameter.

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 ('Set ... the existing anime entry status') and enumerates the allowed values, making clear it touches status only. The clause 'Episode progress is not inferred' plus 'existing anime entry' distinguishes it from update_anime_progress, update_anime_score, and add_anime_to_list without opening their 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 clear operational routing: ordinary single-entry changes execute directly, destructive/bulk changes return a preview that must be repeated with confirmation_id and confirmed:true, and dry_run:true previews anything. It does not explicitly name the sibling tools (update_anime_progress / update_anime_score / update_list_entry) as alternatives, so the agent must infer the boundary from 'only ... status'.

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 flag destructiveHint=true and idempotentHint=false, but the description adds the crucial nuance that ordinary single-entry changes execute directly while only destructive/bulk changes return a preview requiring confirmation_id + confirmed:true. It also discloses that omitted fields are preserved and that dry_run validates without executing — context the 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?

Front-loaded with the action and target, then the field list, then the confirmation workflow — a sensible order with little waste. "Only patch fields explicitly requested" and "Omitted fields are preserved" restate the same guarantee from two angles, a minor redundancy.

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 nested mutation tool with no output schema, the description covers execution vs. preview behavior, dry-run validation, field preservation, and the title-resolution caveat. It leaves the shape of the preview response and any auth/rate-limit constraints unstated, which is a modest remaining gap.

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 71%, and the description reinforces the semantics that matter most: progress/volumes are absolute rather than deltas, and only explicitly requested fields are patched. It also frames the confirmation_id/confirmed pairing as a workflow rather than two bare fields, adding meaning 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?

States a specific verb+resource ("Patch an existing anime or manga entry") and enumerates the patchable fields, which separates it from add_anime_to_list and remove_list_entry. It does not, however, distinguish itself from the specialized siblings update_anime_progress, update_anime_score, and update_anime_status, so the agent must infer that this is the general-purpose path.

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 a clear procedural rule for the preview/confirm flow and for dry_run, which is genuinely useful. But it never says when to choose this tool over the narrower update_* siblings or bulk_update_entries, leaving the main 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 declare destructiveHint=true and openWorldHint=true, but the description adds substantial context on top: the preview/confirm gating flow, dry_run semantics, and that omitted fields are preserved. It stops short of saying what happens when progress exceeds the known total (beyond 'Checks known totals') or what is returned.

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 core action, then the exclusions, then the confirmation flow, then the dry_run escape hatch and the preservation rule. Sentences are tight and every one carries information, though the telegraphic style makes a couple of clauses ('Executes ordinary requested single-entry changes directly') slightly compressed.

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 destructive mutation with no output schema, this covers the key agent-relevant unknowns: how to preview, how confirmation is obtained, and that unmentioned fields are untouched. Return shape and over-total validation behavior are the remaining 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 coverage is high (83%), yet the description still adds real meaning: 'absolute' clarifies that progress is a set value rather than a delta (the schema leaves progress undocumented), and it explains the confirmed/confirmation_id round trip. It does not clarify title-vs-media_id resolution in prose, though the schema covers that.

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 and scope: 'Set absolute chapters read on an existing manga entry.' It also excludes out-of-scope behavior ('Does not request status, score, dates or other field changes'), which cleanly separates it from update_manga_score, update_anime_progress and update_list_entry without opening their 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?

Clear context for the ordinary path ('Executes ordinary requested single-entry changes directly') and an explicit procedure for the destructive/bulk path: preview, ask user, repeat with confirmation_id and confirmed:true. It does not explicitly name update_list_entry as the alternative for multi-field edits, so it falls short of a full when/when-not routing statement.

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 declare destructiveHint=true and idempotentHint=false, and the description adds substantial context beyond that: ordinary single-entry edits execute directly while destructive/bulk changes return a preview, the confirmation_id/confirmed:true repeat protocol, dry_run previewing, and that omitted fields are preserved. That is exactly the write-safety detail the 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?

Front-loaded with the core action and score semantics, then the safety protocol. Dense but nearly every clause carries unique information; the middle sentence ("Executes ordinary requested single-entry changes directly") is the only slightly awkward construction, and the confirmation sentences run long.

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 destructive 6-parameter write tool with no output schema, the description covers mutation semantics, preservation of omitted fields, previewing, and the human-approval workflow. It stops short of describing what the preview response contains or how to interpret the returned candidates when title resolution is ambiguous, though the title parameter's own schema text covers part of 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 83%, so the baseline is 3, but the description adds real meaning the schema lacks: score is interpreted against the owner's scoreFormat enum of five scales, zero clears the score, and no conversion is performed. dry_run and the confirmation protocol are also explained in prose, not just in field descriptions.

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 ("Set an existing manga entry score") and immediately names the domain constraint (owner's scoreFormat with the five concrete formats). An agent can distinguish this from update_anime_score and update_list_entry by the resource alone, 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 clear operational guidance: zero clears, no automatic conversion, dry_run for previewing, and the preview-then-confirm loop for destructive/bulk changes. It does not explicitly route the agent to siblings (e.g. use update_list_entry for status or progress), so a small inference gap remains.

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