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

The annotations declare destructiveHint=false, implying only additive updates, but the description explicitly documents destructive effects: customLists REPLACES the full set and turns OFF previously filed lists, advancedScores omitted categories are set to 0, and existing entries are updated in place. This is a direct contradiction with the destructiveHint annotation.

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 long and dense, but it front-loads the login requirement and core purpose, and the detail is largely warranted for a 14-parameter upsert tool with subtle replacement behavior. Some sentences are run-on and could be structured more cleanly, but there is little obvious waste.

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 complex upsert behavior, 14 parameters, rich schema, and existing output schema, the description covers the important operational context: auth requirement, media ID resolution, existing-entry checks, default/merge behavior, and response echo interpretation. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the individual parameters are already well documented. The description still adds meaningful cross-parameter semantics: omitted fields use defaults only for new entries, while existing entries retain previous values, and it explains when customLists/advancedScores need read-back because they replace rather than merge.

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: adding an anime/manga to the authenticated user's own AniList list, with scope and upsert behavior clarified. It is clear what the tool does, though it does not explicitly distinguish itself from sibling update_list_entry/update_list_entries beyond describing the upsert.

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 concrete prerequisites: requires login, use search_media first to resolve mediaId, and use get_user_list first when a guaranteed-fresh existing entry is needed. It also says to set only fields you care about, but it does not explicitly say when to choose this over update_list_entry or update_list_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?

Annotations already declare destructive=true, idempotent=false and openWorld=true, yet the description adds real value: the login requirement and the concrete failure mode (repeat calls on a deleted id error as not found rather than silently succeeding). The remaining gap is that it doesn't say whether attached replies/comments are also removed.

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 tight sentences: auth requirement and scope first, then irreversibility and repeat-call behavior. 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?

Output schema and rich annotations carry the safety profile, so the description only needs auth, irreversibility and error semantics — all present. It could be more complete by noting cascade effects on child comments for a destructive delete.

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

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

Schema description coverage is 100% and the id field already documents its provenance (get_user_activity, search_activity, prior post_text_activity calls). The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb (Delete) and resource (activity post) plus the ownership constraint, which lets an agent separate it from delete_thread or remove_list_entry. It does not explicitly name an alternative, but the resource is 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 '[Requires login]' tag gives an actionable prerequisite, and 'the authenticated user owns' implies you should only target your own posts. There is no explicit when-to-use vs a sibling (e.g. delete_thread_comment for comment-level removal), so routing 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 destructive/non-idempotent/open-world, so the bar is lower, and the description still contributes real context: login and ownership requirements and the second-call not-found behavior. 'Cannot be undone' largely restates destructiveHint, so the value-add is good but not exceptional.

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 dense sentence with the auth requirement front-loaded, followed by the irreversible/error semantics. No filler and nothing deferred to the end that belongs at the front.

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 destructive mutation with an output schema and full annotation coverage, everything an agent needs is present: auth gate, ownership constraint, ID provenance, irreversibility, and repeat-call 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?

Schema coverage is 100% and there is only one parameter, so semantics are already carried by the schema; the description adds genuine value by telling the agent where a valid ID comes from (search_thread, get_thread, post_thread).

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 (delete) and resource (a forum thread the authenticated user owns, by ID), which cleanly separates it from delete_thread_comment, delete_activity, and the read-only thread tools. The parenthetical naming search_thread/get_thread/post_thread as ID sources removes ambiguity about the input's origin.

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 preconditions: login required and ownership required, plus a warning that repeating the call errors as not found instead of succeeding silently. It never explicitly steers to siblings like delete_thread_comment, so it stops short of a full when/when-not/alternatives 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?

Adds real information beyond the annotations: the auth requirement, the ownership precondition, and the precise repeat-call behavior (a second call errors as not found rather than silently succeeding), which sharpens the generic idempotentHint=false into actionable semantics. Combined with confirming irreversibility, this is behavior an agent cannot get from the structured fields alone.

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 clauses, front-loaded with the auth gate and the action, then the id source, then the destructive and error semantics. No filler sentences and nothing that merely restates the schema.

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

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

For a single-parameter destructive tool with a full annotation set and an output schema, everything an agent needs before invoking — login requirement, ownership, id provenance, irreversibility, repeat-call result — is present. Return values are left to the output schema appropriately.

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% for the single id parameter, so baseline is 3; the description earns above that by explaining where valid ids originate (get_thread_comments, post_thread_comment) and tying the value to the caller's own comments. It adds provenance rather than type detail, 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 ("Delete a comment") plus two scoping constraints: it must be owned by the authenticated user and identified by ID. That scope distinguishes it cleanly from the sibling delete_thread, which deletes a whole thread rather than a comment.

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

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

Gives the precondition ([Requires login]), the ownership restriction, and explicitly names where the id comes from (get_thread_comments or the id returned by post_thread_comment). It stops short of saying when not to use it (e.g. use delete_thread for whole threads), so it is clear but not fully routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered. The description adds the specific returned fields (replyCount, likeCount, isLiked), but that largely duplicates the output schema and gives no extra behavioral context such as not-found handling or auth requirements.

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 that identifies the resource, the lookup key, and the returned highlights with no wasted clauses. The trailing field list is slightly redundant given the output schema but not harmful.

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

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

With a full output schema, complete parameter documentation, and read-only annotations, the description covers what an agent needs to call this simple lookup correctly. Only minor gaps remain, such as error/not-found behavior and explicit sibling routing.

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

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

Schema description coverage is 100%, and the schema already explains that the id comes from get_user_activity, get_user_recent_activity, search_activity, or post creation. The description adds nothing about the parameter beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource — 'Get a single AniList activity post ... by its ID' — and enumerates the activity subtypes (list update, text post, message). The 'single ... by ID' phrasing implicitly separates it from sibling listing/search tools like get_user_activity and search_activity, though it does not name them.

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

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

The 'by its ID' framing implies this is the fetch-one-by-identifier tool, which is a reasonable usage cue. However, it never explicitly says when to prefer this over get_user_activity, get_user_recent_activity, or search_activity, and states no prerequisites or 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?

Goes well beyond the readOnly/openWorld annotations: it discloses the live-verified default of notYetAired=true, that false swaps to a past-only result set rather than appending past episodes, and that a date window overrides the default so a window spanning now returns both. It also discloses the error behavior for manga/non-anime ids (rejected as not-found, indistinguishable from a nonexistent id) which is exactly the kind of failure mode an agent 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?

Purpose and ordering are front-loaded, and every clause carries real information (no filler). However, it is written as a dense run-on with several em-dash asides, making the error-behavior and window semantics harder to scan than they need to be.

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 six-parameter read tool with rich schema coverage, an output schema, and readOnly annotations, nothing an agent needs is missing: defaults, sort order, mode selection, and the manga-id failure mode are all covered.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining mediaId's sourcing and the site-wide interpretation, and by framing the airing window as an alternative mode of use. Some of the notYetAired/window interaction restates the schema text, so it is not fully additive, but it clarifies how the parameters combine in practice.

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 (episode air times), plus the exact ordering (soonest-airing first, or newest-first when notYetAired=false) and scope (anime only, site-wide vs. single title). This clearly separates it from siblings like get_media or get_media_statistics.

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

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

Explicitly tells the agent when to omit mediaId (site-wide schedule), when to pass it and where to get it (search_media/get_media), and when to switch to airingAfter/airingBefore for a date window, with concrete examples (this week, yesterday). It also states the negative case: manga has no airing schedule.

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 mark the tool as read-only and open-world, and the description adds important context: login is required and the tool is the authoritative pre-read source for specific full-replace update fields. It also surfaces the positional risk of advancedScoring, which is meaningful behavioral context beyond the annotations.

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

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

The purpose and login requirement are front-loaded, followed by detailed update-safety guidance. It is somewhat dense and long for a zero-parameter read tool, but the extra detail is relevant to avoiding destructive update mistakes.

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 parameters, a present output schema, and useful annotations, the description covers what the agent needs: auth requirement, purpose, and the critical pre-update role. Nothing essential is missing for correct invocation.

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

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

The tool has zero parameters, so parameter semantics are not a concern and the baseline is 4. The description correctly avoids inventing parameter details for a no-argument 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 states a specific verb and resource: fetching the profile of the currently authorized AniList account. It also distinguishes the tool's role from broader profile lookups by tying it to login/authorization state and account confirmation.

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 names when to use the tool: confirming which account is connected, and fetching current values before update_user operations on notificationOptions, disabledListActivity, customLists, and advancedScoring. The prerequisites and update-related usage are clear.

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

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

Annotations already carry readOnlyHint/openWorldHint, and the description adds real operational context: the pagination trap with hasNextPage, the login requirement for onList, and the errors-if-not-logged-in behavior. Some of that (perPage ceiling, page-depth limit) is already documented in the schema, so the marginal disclosure is good but partly duplicative.

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

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

Purpose and prerequisite are front-loaded in the first two sentences, and every later clause earns its place. The parentheticals and backticked identifiers make it dense and slightly run-on, but nothing is filler.

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

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

An output schema exists, so return values need not be explained; the description spends its words on the one thing an agent could get wrong — treating a single media page as the full filmography — and points at media.pageInfo.hasNextPage. Nothing needed to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds connective meaning beyond the schema — that `type` is applied before pagination so pages stay full, and that omitting `onList` ignores list status rather than defaulting to either side. That is genuine semantic value on top of an already well-documented schema.

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

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

The first sentence names a specific verb and resource ('Get a character's profile by AniList character ID') and enumerates what comes back (name, image, description, media with characterRole). It is unmistakable against the sibling search_character, which is named explicitly as the name-resolution 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?

It gives an explicit precondition ('Use search_character first to resolve a name to its ID') and explicit narrowing options ('Narrow it with `type` ... or `onList`'), plus the alternative of omitting the filter to get both. The when-to-use story is complete.

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

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

Beyond readOnlyHint/openWorldHint it discloses non-obvious behavior: account settings come back regardless of who is authenticated because AniList doesn't viewer-gate those fields, and embedded stats can lag and read all-zero for accounts with real entries. The all-zero caveat is exactly the kind of failure-mode warning that prevents a wrong conclusion.

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 composite purpose, then the sibling substitution, then the caveats — a sensible priority order. It is dense and runs long in a single block, with mild repetition of the get_user_profile/get_user_stats comparison, but no sentence 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?

An output schema exists so return shape needn't be described, and the description covers the remaining risk areas: auth behavior on settings fields, lookup ambiguity, and stale aggregates. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the ID-vs-username typing is already documented; the description still adds the operational nuance that an exact username can be passed directly while fuzzy input needs search_user. That is meaning beyond the schema, though it stops short of anything else about the 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 and resource (get an AniList user's profile AND statistics) plus the composite scope that defines it. It explicitly names the two siblings it replaces (get_user_profile, get_user_stats), so an agent can distinguish it without opening a schema.

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

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

Gives explicit routing rules: use this instead of calling get_user_profile and get_user_stats separately, and no need to call search_user first unless the name is partial/fuzzy. Both the preferred path and the exception condition are spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: this is a canonical reference list whose values are required for valid genre filtering. It does not discuss result size or formatting, but the output schema covers return values.

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, front-loaded with the purpose and followed immediately by the usage instruction and rationale. 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 zero-parameter reference tool with annotations and an output schema, this is complete. An agent knows what it returns, why to call it, and when it should be used ahead of genre-filtered searches.

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; there are no parameter semantics for the description to clarify. The description appropriately focuses on the tool's role rather than inventing parameter guidance.

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 and resource: listing every genre name AniList uses to tag anime/manga. The examples (Action, Comedy, Slice of Life) and the mention of AniList's own vocabulary distinguish it from sibling tools like get_media_tags and search_media.

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 says to call this before filtering search_media by genre and explains why: so the caller passes a name AniList actually recognizes. That gives both a trigger and the alternative context an agent needs.

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

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

Annotations already cover read-only and open-world safety, but the description adds material context beyond them: mediaListEntry requires login, batches beyond 50 are silently clamped, unresolvable IDs come back as null placeholders in the original order, and includeStreamingEpisodes is ignored under compact and unpaginated. The only gap is that response size figures are given but no pagination/rate-limit guidance — minor since batch limits are already stated.

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 core purpose and the IDs-or-malIds constraint are front-loaded, and every sentence carries information about format choice, batching, or return shape. It is a single dense block, though, and it re-explains ids-vs-malIds exclusivity that already lives in the schema 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?

An output schema exists, yet the description still closes the one thing an agent most needs — scalar-in/scalar-out vs array-in/array-out with nulls and preserved order — plus auth-gated fields and the size cost of large batches. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by quantifying the compact/full tradeoff (5KB vs 125KB for 30 titles), explaining when compact is the right choice, and stressing that the wrong `type` with malIds returns the wrong title rather than an error. Some of this restates the schema's own mutual-exclusion notes, which keeps it from a 5.

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

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

States a specific verb and resource ('Get information about one or more anime or manga by their AniList ID(s)') and immediately enumerates what that card contains. It is clearly distinguishable from the sibling search_media, which it names and routes away from.

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?

Explicit decision rules: use search_media only when you have neither ID type, prefer malIds when you already hold MAL IDs, and pass format: 'compact' when the batch's purpose is ID-to-title mapping. This covers when to use, when not to, and which alternative applies.

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

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

Goes well beyond the readOnly/openWorld annotations: discloses result ordering (MAIN, then SUPPORTING, then BACKGROUND, relevance order within each) and the multiplicative response-size effect of returning all dub languages unless filtered. This is exactly the kind of behavior an agent can't infer from structured fields.

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 purpose, then guidance, then ordering and filter notes, with no filler sentences. It is slightly dense in a single paragraph with multiple em-dash asides, but every sentence carries an operational fact.

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

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

With a 100%-covered schema and an output schema, the description only needs to supply routing, ordering, and response-size behavior — and it does all three. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the downstream effect of `voiceActorLanguage` (all dubs returned by default, response bloat) and `role` (single-role filtering). Marginal but real value over the schema text.

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

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

States a specific verb and resource ('List an anime/manga's characters') and immediately enumerates the payload fields (role, voice actors). It is clearly distinguishable from siblings like get_character or get_media_staff.

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

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

Explicitly routes the agent: 'Use search_media first to resolve a title to its AniList ID.' It also gives actionable conditions for optional filters (set `voiceActorLanguage` to narrow dubs, set `role` for one role). It doesn't name when to prefer get_character for a single character, but the primary prerequisite is covered.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine value by spelling out the relationType vocabulary (PREQUEL, SEQUEL, SOURCE, ADAPTATION, etc.), which tells the agent what the returned links mean before it parses the output schema.

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

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

Purpose is front-loaded, followed by the relation vocabulary and then the prerequisite. The long relation list is dense but each term earns its place by defining output semantics; only minor trimming would be possible.

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

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

An output schema exists and annotations cover the safety profile, so the description needn't explain return structure. It supplies the prerequisite and relation semantics; only a note on behavior when no relations exist (empty list vs. error) is arguably 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%: both `id` and `type` are documented in the schema with an enum for ANIME/MANGA. The description adds nothing about parameter formatting, so baseline 3 is appropriate when the schema carries the load.

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

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

States a specific verb and resource ("get the anime/manga related to a given title") and enumerates the exact relation types returned. This clearly separates it from siblings like get_media, get_recommendations_for_media, and get_media_characters, which cover adjacent but different data.

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 instructs "Use search_media first to resolve a title to its AniList ID," which is the key prerequisite an agent would otherwise miss. No when-not-to-use exclusions are given (e.g., versus get_recommendations_for_media), but the usage context is unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds live-verified behavioral detail the annotations don't carry — the ordering is by `rating` not `score` — and warns that includeBody can return long text. It doesn't mention the ~5000-entry paging ceiling, though the schema does.

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, front-loaded with purpose and ordering, then output shape, then the prerequisite lookup. Dense with nested parentheticals and backticks, which costs a little readability but every clause carries information.

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

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

With an output schema present, return values needn't be explained, yet the description helpfully notes that `summary` is always included. The ordering caveat, the includeBody cost, and the ID-resolution prerequisite cover what an agent needs to invoke it correctly; only the paging depth limit is left to the schema.

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

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

Schema coverage is 100%, so baseline is 3. The description still earns a notch above by framing includeBody as a cost/benefit tradeoff (full text 'can be long') and by tying `id` to the need for a resolved AniList ID, which the schema's bare 'AniList ID' does not operationalize.

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

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

States a specific verb and resource ('List user-written reviews for an anime or manga') plus the ordering, and it is clearly distinguishable from siblings such as get_media or get_media_statistics. The parenthetical naming the ordering field ('rating', not 'score') pins down the resource further.

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

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

Explicitly routes the agent to search_media first to resolve a title to an AniList ID, and gives a use/don't-use rule for includeBody ('leave it off unless you actually need the full text'). No exclusions relative to a competing sibling, but none plausibly exists for this resource.

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?

With readOnlyHint and openWorldHint already declaring the safety profile, the description contributes the non-obvious trait that results carry no guaranteed ordering — a genuine behavioral caveat an agent would otherwise mis-infer. It also flags the contrast with get_staff's sorting. It does not discuss result volume or pagination depth, but the schema already documents that.

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

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

Three sentences, each carrying distinct information: what is returned, the ID-resolution prerequisite, and the ordering caveat. The final sentence is long but front-loads the caution ("No explicit ordering is requested") before the comparison, so it reads cleanly.

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 4-parameter read tool with a full schema and an output schema, the description covers the only things the structured fields cannot: how to obtain the ID and that ordering is unspecified. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, including the pagination clamp and perPage ceiling, so the schema does the heavy lifting. The description reinforces that `type` selects anime vs manga and that `id` must come from search_media, but adds no format or edge-case detail beyond 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 specific verb and resource ("List an anime/manga's staff ... with their role") and enumerates the role types returned. It explicitly distinguishes itself from get_staff by calling that tool a "reverse-direction lookup," so an agent can separate the two without opening schemas.

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

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

Gives a concrete prerequisite workflow: use search_media first to resolve a title to an AniList ID. It also sets an expectation against a sibling (get_staff is popularity-sorted, this is not). It does not address other plausible siblings such as search_staff or get_character, so it falls just short of a full when/when-not guide.

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 carry readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds a genuinely useful behavioral fact by specifying the counts are aggregated 'across all AniList users' rather than scoped to the authenticated user, plus the ID-resolution prerequisite. It does not discuss data freshness or empty-distribution cases, but that is a modest gap given annotation coverage.

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, zero filler: the capability and its scope come first, the prerequisite second. Nothing could be removed without losing information.

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

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

With an output schema present, return-value explanation is unnecessary, and the description covers purpose, aggregation scope, and ID-resolution workflow for a 2-parameter read tool. Only minor edge-case behavior (invalid ID, empty distribution) is left unstated.

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

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

Schema description coverage is 100% and both parameters are documented there, so the schema does the heavy lifting and baseline 3 applies. The description reinforces that `id` must be an AniList ID obtained via search_media and implicitly ties `type` to whether the ID is anime or manga, but adds no syntax or constraint detail 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 pair ('get an anime/manga's watch/read-status counts and score distribution histogram') and scopes it to 'all AniList users', which separates it from sibling aggregations like get_site_statistics and per-media tools like get_media. An agent can distinguish this from get_user_stats and get_media 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?

Explicitly tells the agent to 'Use search_media first to resolve a title to its AniList ID', which is the key workflow prerequisite since the tool takes a numeric ID rather than a title. It stops short of naming when-not-to-use or what happens with an invalid/unresolvable ID.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds real behavioral context: ~425 total tags, results paginated, and the non-obvious silent-no-match failure mode confirmed live. It does not cover rate limits or auth, so it stops just short of the top mark, but the added value over the annotations is substantial.

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, front-loaded with purpose before caveats, and every clause adds information an agent needs: tag granularity, volume/pagination, and the search_media handoff plus case-sensitivity gotcha. No filler.

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

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

An output schema exists, so return values need no elaboration, and the description still sketches the payload ('category and adult-content flag'). For a two-optional-parameter read tool with annotations, pagination guidance and the tag-name lookup rationale cover everything needed 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?

Schema coverage is 100% and both parameters carry detailed descriptions, so the baseline is 3. The description earns a bump by explaining why pagination matters here ('~425 tags total, so results are paginated — use `page`/`perPage` rather than expecting them all in one response'), turning a mechanical parameter into a usage decision.

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

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

States a specific verb and resource ('List every descriptive tag AniList uses on anime/manga') and immediately differentiates it from the sibling concept of genres ('finer-grained than genres'). Concrete examples ('Time Skip', 'Tragedy') and the mention of category and adult-content flag make the output shape predictable.

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 gives the downstream use case: look up a tag's exact name before passing it to search_media's `tag_in`. It names the sibling tool and the condition that selects this one, and warns that tag names are case-sensitive and an unrecognized name silently matches nothing rather than erroring — a precise when-to-use rationale.

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?

Critically, it discloses the non-obvious side effect that markAsRead clears the unread badge, which explains why readOnlyHint is false despite the 'Get' framing. It also documents that returned fields vary by notification type, including the subtle nesting of the DM text inside message.message — real behavioral detail beyond the annotations.

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

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

Front-loaded with the auth requirement and core purpose, then a dense but useful second sentence on item shape. Slightly long and parenthetical-heavy, but every clause conveys information an agent would otherwise have to discover empirically.

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

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

An output schema exists, yet the description still adds the essential insight that fields depend on type, which is exactly the kind of variability a schema alone would obscure. Auth requirement, side-effect behavior, and filter interactions are all accounted for.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds genuine value by explaining the type-dependent shape of returned items (AIRING includes media/episode, FOLLOWING includes user, ACTIVITY_MESSAGE nests text). It doesn't restate page/perPage/markAsRead semantics, which the schema already carries well.

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

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

States a specific verb and resource ('Get the authenticated user's AniList notifications') and enumerates the concrete notification categories covered, so an agent immediately knows the scope. No sibling tool overlaps this function, and the description makes that distinct role obvious.

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 '[Requires login]' prefix establishes the auth precondition, and the type_in description explains the interaction with the account's notificationOptions setting. It does not explicitly say when to prefer or avoid this tool, but with no close sibling alternative there is nothing to disambiguate against.

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

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

Annotations only say readOnly and openWorld; the description adds genuinely non-obvious behavior: a majority of IDs sourced from get_recommendations_for_media's nodes[].id 404 here (7 of 10 tested), with no correlation to rating, and that a 404 does not mean the pairing doesn't exist. That is exactly the failure-mode context an agent cannot get from structured fields.

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 core purpose is front-loaded in the first clause, but the single sentence is very long with nested em-dashes and parentheses carrying the voting aside, the sibling routing, and the 404 statistics. The content mostly earns its place, yet the packing makes it harder to scan than a three-sentence split would be.

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 tool with an output schema, the description covers everything an agent needs: what it returns conceptually, which sibling to use instead, and the known ID-resolution failure mode. Nothing material 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the id is an AniList-side recommendation ID whose provenance (nodes[].id from the sibling tool) and reliability (often 404) are called out. It still doesn't add format/range hints beyond the schema's own constraints.

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

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

States a specific verb and resource ('Get a single AniList recommendation pairing ... by its AniList recommendation ID') and explicitly scopes what a recommendation is (media + the recommended-alongside media). It also names the sibling get_recommendations_for_media for the adjacent task, so an agent can tell the two apart without opening either schema.

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

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

Gives an explicit when ('re-checking one specific pairing's current rating/userRating after voting on anilist.co') and an explicit when-not/alternative ('use get_recommendations_for_media instead to discover recommendation IDs ... or to browse/list them'). It also rules out a mistaken expectation by noting this server has no vote-casting 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses ranking order, login requirements for mediaListEntry, and that excludeInList is a local post-fetch filter rather than AniList's own onList filter. It also notes the consequence that a page may return fewer than perPage results, which is useful behavioral context not covered by 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 three tight sentences with no filler, and the core purpose and ID-resolution prerequisite are front-loaded. The parenthetical about onList is dense but earns its place by preventing a concrete filtering mistake.

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 listing tool with an output schema and full annotations, the description covers everything an agent needs: what is returned, ranking order, prerequisite ID resolution, login-dependent fields, and excludeInList gotchas. Pagination and numeric limits are already handled by the schema descriptions.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema by explaining that excludeInList filters after fetching and that AniList's native onList filter applies to the source title, not the recommended one. It also clarifies mediaId's role by directing the agent to search_media for resolution.

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

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

The description states a specific verb and resource: list recommendations for a given anime/manga title, ranked by rating. It clearly separates this from search_media by instructing the agent to use search_media first for ID resolution, and the scoped wording distinguishes it from the singular get_recommendation sibling.

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

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

It gives clear usage context by telling the agent to use search_media first to resolve a title to an AniList ID, and it explains when to set excludeInList. It does not explicitly name when not to use this tool or compare it against get_recommendation, so it falls short of full when/when-not guidance.

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

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

Annotations only cover readOnlyHint/openWorldHint, and the description adds genuinely non-obvious behavior: newest-first ordering, a 7-day default window, and the fact that AniList silently caps perPage at 25 so the tool's own cap is lossless. That upstream silent-cap disclosure is exactly the kind of context an agent can't get from structured fields. It's slightly muddled in phrasing but the substance is there.

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

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

Front-loaded with the essential purpose and the key exclusion before the operational details. The final sentence is convoluted and partially restates the schema's perPage cap note, costing some efficiency, but no sentence is pure 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 two-parameter read-only listing tool with an output schema and full schema coverage, the description supplies purpose, exclusion, default behavior, ordering, pagination strategy, and the upstream cap caveat. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: page/perPage are the mechanism for reaching further back than the default window, and perPage above 25 is pointless regardless of the tool's own limit. That is actionable guidance beyond the schema's 'maximum: 25'.

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

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

States a specific verb and resource ('Get AniList's own site-wide statistics') and immediately enumerates what the payload contains (new users/anime/manga daily counts). The clause 'not for anime data' cleanly separates it from siblings like get_media_statistics and get_user_stats.

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

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

Explicitly frames the intended question type ('AniList's growth/activity') and states an exclusion ('not for anime data'), which is enough to route an agent correctly. It stops short of naming the specific sibling to use instead for anime data, so it doesn't quite reach the 5 bar of naming alternatives.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds live-verified behavioral facts: production credits exclude voice roles, either list is paginated and must be checked via pageInfo.hasNextPage before being treated as complete, and onList errors when unauthenticated (AniList would otherwise silently ignore it). That is real context beyond the annotations, though the 5000-entry paging ceiling is left to the schema.

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

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

Front-loaded with the core purpose, and the voice-credit caveat is well placed after the primary behavior. It is dense but mostly earns its length; the trailing 'Either list is paginated (page/perPage, max 25)' and the onList parenthetical partially duplicate schema text.

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

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

For a 6-parameter read tool with an output schema, the description covers the identity requirement, field shape differences between credits modes, pagination completeness caveat, and the auth precondition for onList. Nothing an agent needs before calling is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning, explaining that credits:"voice" returns characterMedia with characterRole rather than staffMedia with staffRole, and that type/onList narrow the filmography. Some content (perPage max 25, page mechanics) merely restates 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 and resource ('Get a staff member's profile by AniList staff ID') and immediately enumerates the returned fields (name, image, occupations, description, staffMedia). It also distinguishes itself from the sibling search_staff, which resolves names to IDs rather than returning 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?

Explicitly routes the agent: 'Use search_staff first to resolve a name to its ID', and gives a conditional rule for choosing between the two filmographies ('for a voice actor, pass credits: "voice"'). It also scopes the type and onList filters to a specific use case, leaving little 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 readOnlyHint/openWorldHint, and the description adds genuinely useful behavior: a 25-result pagination ceiling, the hasNextPage caveat before treating media as a full catalog, and that media mixes main-studio and producer credits by default. It does not mention the login requirement or error behavior of onList (only the schema does), so it adds context but not a complete behavioral picture.

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

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

Purpose and return shape are front-loaded, followed by pagination, filtering, and routing caveats in that order. Every sentence carries new information; nothing restates the title or schema verbatim.

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 six optional params, an output schema, and full schema coverage, the description supplies the missing decision layer: default-vs-filter semantics, pagination limits, fuzzy-name behavior, and precedence. An agent can call this correctly without further discovery.

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 goes beyond it by explaining the default mixing of main/non-main credits and the isMain split, plus the id-takes-precedence rule that the schema leaves ambiguous ('Provide this or name'). It adds nothing extra for page/onList beyond what the schema already documents.

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 ('Get a studio's profile') and enumerates what comes back (name, isAnimationStudio, credited media sorted by popularity), keyed by AniList studio ID or name. The final sentence routes the agent away from search_studio, so it is distinguishable from its closest sibling 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?

Explicitly says when to reach for search_studio ('only when you need to browse multiple candidates rather than take the closest match') and confirms partial names resolve via AniList fuzzy search. It also states the id-over-name precedence rule and when to toggle isMain, leaving nothing 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the thread's title, body and metadata (replyCount, viewCount, likeCount, isLiked) are returned, which is modest extra context — though most of that duplicates the output schema. It says nothing about authentication (isLiked is user-relative) or error behavior for missing/deleted threads.

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 sentence, front-loaded with the verb and resource, then the returned fields. Zero padding or redundant phrasing.

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

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

With an output schema covering return values, full parameter documentation, and annotations carrying the read-only/open-world profile, the description supplies enough for correct invocation. The only gap is that it doesn't flag that this is a read sibling of delete_thread/search_thread or mention auth-sensitive fields.

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%: the single 'id' parameter is fully documented in-schema, including how to obtain one and URL examples. The description only restates 'by its ID' and adds no syntax or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('AniList forum thread') plus the retrieval key ('by its ID'), so the operation is unambiguous. It doesn't contrast itself with the sibling search_thread inside the description text, leaving sibling differentiation to 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?

'By its ID' implies this is a direct lookup rather than a search, which hints at when to use it versus search_thread. However, the explicit routing advice ('use search_thread to find one') lives only in the parameter schema, not the description, so the guidance in the description itself 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: replies are not returned as separate list entries but nested under each parent's childComments field, which materially affects how the agent interprets the response shape.

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, zero waste. The core action and scope come first, and the nesting caveat follows as a tightly scoped second sentence that earns its place by preventing a real misreading of results.

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

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

With an output schema present and full parameter documentation in the schema, the description doesn't need to explain return values or pagination. It covers scope and the one non-obvious structural behavior (nested replies); the only minor gap is nothing about ordering or page-size limits, which the schema already handles.

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

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

Schema coverage is 100% and each parameter (threadId, page, perPage) already carries a detailed description, including pagination ceilings and clamping behavior. The description's only added parameter framing is 'by the thread's ID', which the schema already states. Baseline 3 applies.

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

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

States a specific verb and resource ('List top-level comments posted on an AniList forum thread') and explicitly names the scope ('by the thread's ID'). The 'top-level' qualifier plus the contrast with replies makes it immediately distinguishable from siblings like get_thread and post_thread_comment.

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 makes clear when this tool applies (fetching a thread's comment list) and points to post_thread_comment as the source of replies, implicitly telling the agent that posting is not this tool's job. It stops short of naming an explicit alternative for reading replies other than noting they arrive nested in the parent 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 readOnlyHint and openWorldHint, and the description adds material context beyond them: pagination must be checked via hasNextPage because a day can exceed a thousand entries, results are truncated relative to the singular tools, and bios are omitted by default. It also explains why includeDescription is off (token cost).

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 ordering, then pagination, then result shape and the fallback to sibling tools. Dense but nearly every clause carries information; the final filmography warning is slightly repetitive with the preceding sentence but still earns its place as a misread guard.

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

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

An output schema exists, so return values needn't be spelled out, yet the description still characterizes the character-shaped vs staff-shaped objects and what is absent from them. Combined with pagination and permission-free read semantics, an agent has everything needed to call correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining the default-off rationale for includeDescription and reinforcing that omitting it hides `description`, plus the pagination-limit behavior tied to `page`. It does not add new syntax or format detail beyond 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 specific verb+resource+scope: list AniList characters or staff whose birthday (month/day) is today, ordered by favourites. It explicitly distinguishes itself from get_character/get_staff by describing the lighter shape it returns.

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

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

Gives explicit when-to-use (birthday-by-day listing) and when-not-to (call get_character/get_staff by ID for full roles/works and bio), plus an interpretation caveat: don't read a missing filmography as 'none'. The alternative and its triggering condition are named.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious behavior: the username is resolved to an id with one extra internal lookup, and an unknown ID/username errors rather than returning an empty feed. It does not discuss ordering guarantees across pages or rate limits, which keeps it short of a 5 given the lowered bar annotations provide.

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 sentences, each carrying distinct information: scope, filtering strategy, username handling, then two explicit alternative routings. Nothing is redundant and the core scope is front-loaded.

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

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

With an output schema present, return-value explanation is unnecessary, and the six parameters are fully documented in the schema. The description closes the remaining gaps an agent would care about — naming semantics, error-on-unknown-user behavior, and which sibling to use instead.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by stating the default (all activity types) and by explaining the intended use of `type` and the createdAfter/createdBefore window as server-side narrowing levers rather than post-filtering. It slightly exceeds the schema's own field-level docs without duplicating 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?

Opens with a specific verb and resource ('List recent AniList activity posts from a specific user, newest first') plus the default scope (every activity type, with the types enumerated). An agent can distinguish this from search_activity and get_user_recent_activity 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?

Explicitly routes away from two siblings: 'Use search_activity instead to browse without pinning to one user' and 'Use get_user_recent_activity instead if you just want a quick, fixed-size (5-item) recent snapshot without paginating.' It also tells the agent to filter server-side with type/createdAfter/createdBefore rather than paging and discarding, and clarifies that calling search_user first is unnecessary.

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

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

Annotations only declare readOnly/openWorld; the description adds substantial non-obvious behavior — full responses are ~10x larger per entry, chunking counts across all statuses combined, groups are not interleaved, `perChunk` is uncapped, and the collection is hard-capped at ~11,000 most recently updated entries beyond which data is unrecoverable by any chunk. That ceiling and the size tradeoff are exactly the context annotations cannot supply.

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?

It is front-loaded correctly — default format and purpose come first — but it is a single ~250-word paragraph that restates several already-documented schema facts (perChunk has no cap, sort applies before chunking, statuses shrink the response). Those repetitions would not survive an edit that treats the schema as authoritative.

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

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

An output schema exists, so return values need no explanation, and the description still covers everything else an agent needs to call this correctly: user identification form, pagination loop via hasNextChunk/chunk, response-size tradeoffs, filtering strategy, and the upstream data ceiling. Nothing material is missing for an 11-parameter read 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 coverage is 100%, so the baseline is 3, and much of the description's parameter talk (perChunk cap, sort-before-chunking, statuses filtering rationale) repeats what the schema already documents. It earns one step above baseline by supplying a concrete worked range example for the date bounds and by explaining cross-parameter interaction (sort + perChunk + statuses yields a ranked top-N).

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

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

States a specific verb and resource ('Get a user's AniList anime or manga list') and immediately describes the default return shape (compact one-row-per-entry table with named fields). It also distinguishes itself from the closest sibling by noting an exact username needs no prior search_user call, so an agent can pick it 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?

Explicit branching guidance: use compact by default, switch to full 'only when you actually need dates, notes, custom lists...'; filter with `statuses` rather than client-side discarding; use `completedAt_*`/`startedAt_*` bounds instead of scanning. It even names the alternative tool (search_user) and the condition that makes it unnecessary.

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

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

Beyond readOnlyHint/openWorldHint, the description discloses a non-obvious behavioral fact: account settings are not viewer-gated and are returned for any user, not just the authenticated caller — this is the kind of privacy/auth behavior annotations cannot express. It also notes the 'confirmed live' verification, which raises trust in that claim.

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

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

Front-loaded with what it returns, then the privacy caveat, then the routing advice — a sensible order with no filler. The middle sentence runs long and packs two ideas (non-gated settings plus the implication you can inspect other users), slightly reducing scannability.

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?

Only one required parameter, fully documented by the schema, an output schema exists so return values needn't be described, and annotations cover the safety profile. The description adds the auth-visibility nuance and sibling routing, leaving nothing an agent needs missing.

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

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

Schema coverage is 100% and the schema already documents the integer-vs-string username interpretation, so the description adds little on the parameter itself. Its only value-add is procedural (don't call search_user first), which is usage guidance rather than parameter semantics. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get an AniList user's public profile') and enumerates the returned content: name, about, avatar, donator status, and account settings. It also differentiates itself from the nearest siblings by naming search_user, get_user_stats, and get_full_user_info, so an agent can route correctly without opening schemas.

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

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

Gives explicit routing rules both directions: skip search_user when you have an exact username, use search_user only for partial/fuzzy names, and use get_full_user_info instead of also calling get_user_stats. These are concrete when-to-use and when-not-to-use statements with named alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds real behavioral context: fixed non-configurable count, no type filter applied by the underlying query, full content rather than IDs, and that username resolution costs an internal lookup either way. Covers most of the behavioral surface, though it does not mention failure modes beyond what the schema documents.

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 scope, then alternatives, then parameter behavior. Dense and largely waste-free, but the long parenthetical about activity types and the lookup-cost aside make it feel heavier than a one-param read tool needs.

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

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

With an output schema covering return values and annotations covering safety, the description only needs to establish scope, alternatives and input behavior, and it does all three. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% and already documents the ID-or-username union and that unknown values error. The description nonetheless adds callable-path meaning: an exact username can be passed directly without a search_user pre-call, and resolution cost is constant. That is genuine value beyond the schema, just for a single param.

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 and scope: the 5 most recent activity posts with full content, covering every activity type. It explicitly names the sibling it is not (get_user_activity) so an agent can route between them 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 the alternative (get_user_activity for a paginated full feed) and the condition for choosing it, plus a precondition note about when search_user is and is not needed. This is exactly the when/when-not/alternatives guidance the dimension rewards.

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 annotations' readOnly/openWorld hints, the description discloses a non-obvious AniList-specific behavior: stats aggregation can lag and return all-zero data even when the account has real activity. It tells the agent not to treat zeroed results as conclusive without checking get_user_list.

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

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

The description is front-loaded with the tool's purpose and then spends its remaining sentences on actionable routing and caveats. The anecdotal detail about zeroed statistics directly supports a real invocation risk, so it earns its place.

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

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

An output schema exists, so the description need not document return fields. For a one-parameter read-only stats tool, it covers purpose, accepted input style, alternatives, and the key reliability caveat.

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

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

Schema coverage is 100%, so the baseline is already high, but the description adds practical meaning by emphasizing that an exact username is accepted directly and that fuzzy names should route through search_user. It does not add further detail about the ID-versus-username distinction 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?

The first sentence states a specific verb and resource: gets an AniList user's anime/manga statistics, then enumerates what those statistics include. It is immediately distinguishable from siblings like get_user_profile and get_user_list.

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 says an exact AniList username can be passed directly and that search_user is unnecessary unless the name is partial/fuzzy. It also names get_user_list for cross-checking zeroed results and get_full_user_info as the alternative when profile data is needed.

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 context beyond annotations: it discloses the auth flow, the external dependency (browser/AniList), required env configuration, and a non-obvious caveat that auto_capture is not a reliable remote/headless detector. That caveat is exactly the kind of behavioral insight 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?

Front-loaded with purpose then prerequisites then flow. The auto_capture caveat is long and slightly dense but carries real value; a small trim would improve it without losing meaning.

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 an output schema exists, the description needn't enumerate return fields, yet it still explains the key response element (authorization URL, auto_capture). The full multi-step flow is covered so an agent can act 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?

Zero parameters, so the baseline is 4. The description usefully documents config inputs (ANILIST_CLIENT_ID, ANILIST_CLIENT_SECRET, ANILIST_OAUTH_PORT) that affect behavior, though these aren't schema parameters.

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 and resource: 'Authorize the personal-list and social tools with your AniList account (one-time)'. It is clearly distinguishable from sibling read tools and names submit_anilist_redirect as the follow-up 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?

Explicit when-to-use (one-time authorization for personal-list/social tools), detailed prerequisites (developer app, exact Redirect URL, env vars), and a named alternative path via submit_anilist_redirect with the condition that selects 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 this is a non-readonly, open-world, non-destructive mutation, and the description adds substantial context: login is required, posts are publicly visible on both profiles/feeds, and the tool omits AniList's underlying `private` argument. These are exactly the behavioral details an agent needs for privacy-sensitive use.

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

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

The description is front-loaded with the login requirement and core action, then spends its remaining sentences on the critical public-visibility warning. There is no filler; each sentence adds either a usage constraint or a privacy clarification.

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

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

The tool is a mutation with an output schema, full parameter documentation, and annotations covering safety. The description fills the remaining critical gap — public visibility and lack of a private option — so an agent has everything needed to invoke it responsibly.

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

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

Schema description coverage is 100%, so the schema already documents `id`, `message`, and `recipientId` thoroughly, including the username-to-ID resolution hint. The description adds the high-level update-via-`id` behavior but no new parameter-level 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?

The description states a specific verb and resource: posting a message-style activity to another AniList user's profile, or updating an existing one via `id`. It explicitly distinguishes this from a private DM and from `post_text_activity`, so an agent can identify the 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?

It gives a clear when-not condition: do not use it for confidential content because the output is public. It also mentions `post_text_activity` as a similar public posting tool, but does not explicitly compare when to choose one over the other.

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=false, idempotent=false, openWorld=true and destructive=false. The description adds genuinely non-redundant context: authentication is required, the target is restricted to the caller's own profile (no posting to other users), and the id parameter switches the call from create to mutate semantics.

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 sentence, front-loaded with the login prerequisite and the primary action, with the update variant following as a compact clause. No filler.

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

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

An output schema exists, so return values need not be explained. For a 2-parameter mutation the description covers auth, target scope, and the create-vs-update branch, leaving nothing an agent needs before calling 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?

Schema description coverage is 100%, including the 5-10000 character range and the id-as-update semantics, so the schema already carries parameter meaning. The description's phrasing about `id` largely restates the schema's own 'update instead of creating a new post' wording rather than adding new detail.

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 (post/update) and resource (text-status update on AniList profile) with scope clearly limited to the authenticated user's own profile. The 'text-status' qualifier distinguishes it from the sibling post_message_activity without opening either schema.

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

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

Explicitly splits the two modes: create a new post by default, or update an existing one by passing `id`. The '[Requires login]' prefix gives an actionable prerequisite. It stops short of naming alternatives (post_message_activity, delete_activity) for cases where the agent wants a non-text activity or removal.

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 cover the safety profile (not read-only, not destructive, not idempotent, open-world), and the description adds genuinely valuable behavioral facts: sticky/locked can silently no-op without moderator permission, and categories/mediaCategories are full replaces that drop existing values silently. What holds it back from a 5 is that much of the category-drop detail is duplicated verbatim from the schema field descriptions rather than adding new information.

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 create/update distinction, and every sentence carries operational weight. It's dense but a bit repetitive, restating the categories-drop caveat already present in the schema, and the parenthetical 'see those fields' own descriptions below' is mildly awkward.

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 mutation with an output schema, the description covers the gaps that structured data cannot: that the response omits categories/sticky/locked and that a follow-up get_thread read is needed to confirm application. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra credit for summarizing the critical semantic — that `id` switches the tool from create to update mode and that create-vs-update changes which fields are required. It does, however, point to field descriptions 'below' rather than adding materially new semantics for locked/sticky.

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 ('Post a new forum thread') and clarifies dual semantics: create by default, update when `id` is supplied. It's clearly separable from siblings like delete_thread, get_thread, and search_thread.

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

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

Gives explicit before/after guidance: use search_thread first to check for duplicates, and call get_thread afterward to verify category/sticky/locked changes. It also states the login requirement, which gates use entirely.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the genuine, non-annotated context that authentication is required and that the comment is attributed to the authenticated user. It says nothing about ownership rules for edits, notifications, or rate limits, so the added value is modest but real.

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 with the authentication prerequisite front-loaded and the update mode appended; no redundant restatement of the title or schema.

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

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

An output schema exists, so return values need no explanation, and annotations plus the auth note cover the interaction contract. It is only slightly short of complete because editing someone else's comment versus one's own is unaddressed for a mutation tool.

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

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

Schema description coverage is 100%, and the schema itself already explains `id` vs `parentCommentId`, thread IDs, and the markdown character limit in detail. The description only reinforces the `id` = update behavior already documented in the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Post a new comment on an AniList forum thread') and disambiguates the create-vs-update behavior in the same sentence. An agent can distinguish it from delete_thread_comment and post_thread 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?

The '[Requires login]' prefix and 'from the authenticated user's account' establish the prerequisite, and the description explicitly says to use `id` to update rather than create. It does not name a sibling alternative or state when this should be chosen over post_thread, so it stops short of full routing guidance.

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

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

Beyond destructiveHint=true and idempotentHint=false, it spells out the concrete consequence: irreversible deletion, plus a second call on the same id errors as not found rather than silently succeeding. That is exactly the non-idempotent destructive behavior an agent needs to reason about retries, and the login requirement is stated up front.

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 compact sentence front-loads the auth requirement, then the action, then the id caveat, then the irreversibility warning. No filler, and the failure-mode detail is attached to the sentence it qualifies.

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

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

With an output schema present, return shape needn't be explained, and annotations carry the safety profile. Auth requirement, id source, irreversibility, and re-call failure behavior are all covered, leaving no meaningful gap for a one-parameter destructive 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 coverage is 100% and the parameter description already says 'ENTRY id, not the media id', so baseline would be 3. The description adds provenance the schema cannot — where to obtain the id (get_user_list) — which materially reduces the risk of passing a media 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 and resource (delete an entry from the authenticated user's own list) and explicitly contrasts list-entry ID with media ID, which separates it from add_list_entry/update_list_entry and get_media operations at a glance.

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

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

Gives the preconditions (requires login, must be the authenticated user's own entry) and points to get_user_list as the source of a valid id. It stops short of naming the alternative to use when the goal is to change status or score rather than remove the entry (update_list_entry), so routing is clear but not exhaustive.

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 readOnlyHint/openWorldHint annotations: it discloses that each result embeds content, counts, isLiked, user and media, that isFollowing errors before any request without a token (and returns only own activity if following nobody), and that an unknown user errors with not_found rather than an empty list. These are exactly the behavioral facts an agent needs before calling.

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, front-loaded with the resource and filter set, then the return-content/exclusion note. The nested parentheticals and em-dashes make it dense, but every clause carries information an agent would otherwise have to infer.

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

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

With an output schema present, the description doesn't need to restate return shape, yet it summarizes what comes back and covers auth, error, and no-follow-up-call behavior — enough to invoke correctly. The one gap is not steering the agent away from overlapping siblings when a single user's feed is the actual goal.

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

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

Schema description coverage is 100%, so the schema already explains pagination limits, perPage clamping, enum/array behavior for type, and the createdBefore/createdAfter precision. The description only echoes the filtering dimensions and the [Requires login] tag for isFollowing, adding little beyond structured fields. Baseline 3 applies.

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

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

States a specific verb+resource ('Search/browse AniList's activity feed') and enumerates the activity subtypes (list updates, text posts, messages) plus the filterable dimensions. Scope is clear enough to distinguish it from the single-activity sibling get_activity, though it never names get_user_activity or get_user_recent_activity, leaving that separation 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 actionable routing advice: no follow-up get_activity call is needed because results carry full content, unless you later need to re-check a specific result's counts, and no search_user call is needed for exact usernames. It also states the isFollowing login precondition and that it can't combine with user. It stops short of explicitly contrasting with get_user_activity/get_user_recent_activity.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description usefully builds on them by disclosing output behavior: IDs are returned for follow-up calls and each result's `description` field is withheld unless the flag is set. The token-cost rationale adds genuine context. It leaves pagination depth limits to the schema, which is a minor omission rather than a gap.

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

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

Three tight sentences with no redundancy: purpose first, then the follow-up tool, then the one non-obvious output toggle. Nothing is buried or repeated.

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

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

With an output schema present, rich annotation coverage, and 100% schema descriptions, the description only needs to orient the agent — which it does by naming the resource, the returned ID, and the omitted bio field. Nothing needed to call this correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters are already fully documented upstream, including the perPage ceiling and the page × perPage limit. The description only restates the includeDescription default and term-by-name semantics, adding little beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb and resource ('Search AniList for characters by name') and immediately contrasts with the sibling get_character by saying it returns IDs for use with it. An agent can distinguish this from search_media, search_staff, and search_studio purely from the description.

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?

Clearly positions the tool as a discovery step feeding into get_character, and names get_character as the alternative when a single full bio is needed. It stops short of explicit 'do not use for X' exclusions, but the routing between search and fetch is unambiguous.

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

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

Adds behavior annotations don't carry: adult/NSFW results are included by default unless `sfw: true` or `isAdult: false`, and `isAdult: true` inverts it — a genuine safety and result-set fact. It also notes exclusion-variant filters and the ranking browse mode, all beyond readOnly/openWorld hints.

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, front-loaded with the primary search mode, then the browse fallback, then the adult-content default, then the return type. The parentheticals are dense but each clause carries a distinct decision-relevant fact.

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 39 parameters, a full input schema, an output schema, and annotations, the description covers the decisions the schema can't: which mode to use, what the safety default is, and what the tool hands back. Nothing an agent needs before calling 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 still adds value by tying `sort` to the term-less browse case and explaining the sfw/isAdult equivalence, which spans two parameters. It doesn't survey the other 35 filter params, but the schema already documents those thoroughly.

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 concrete verb and resource ("Search AniList for anime or manga") and covers both modes: title/filter search and term-less ranking browse. It also distinguishes itself from the ID-based siblings by noting it returns AniList IDs consumed by get_media, so an agent can place it in the workflow 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?

Explicitly says to browse term-less via `sort` when you have no title, and points to get_media for a single title's synopsis and get_genres/get_media_tags for valid filter names. What's missing is a direct statement of when to prefer search_media over get_media for a lookup, but the routing is otherwise clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavior beyond that: results' bios are omitted by default and must be opted into, which affects token cost and downstream calls.

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

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

Three short sentences: purpose first, then the ID hand-off, then the one non-obvious default. No filler, and the most actionable constraint 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?

An output schema exists and annotations cover safety, so the description needn't explain return shapes. Combined with rich parameter docs, an agent has everything needed to pick and call this tool correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning by explaining that each result's `description` field is omitted unless `includeDescription` is set — context the schema states more tersely. It does not address pagination, but the schema covers that thoroughly.

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 AniList for staff members by name') and immediately frames the output's purpose (IDs for get_staff). This cleanly distinguishes it from sibling get_staff and from search_character/search_user/search_studio.

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

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

Explicitly routes the agent: use this to obtain IDs, then call get_staff, and use get_staff directly for a single entry's full bio. It gives a clear context but stops short of stating exclusions such as when not to search at all or how it compares to get_todays_birthdays-style browsing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds non-obvious workflow context by stating the output is AniList IDs meant to be fed into get_studio, which is genuine chaining guidance beyond the structured fields. Pagination limits are left entirely to the schema, which documents them thoroughly.

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, front-loaded with the action and scope, then the sibling disambiguation. The dense phrasing about get_studio's `name` param earns its length because it prevents a redundant call.

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?

Read-only annotations cover safety, an output schema exists, parameters are fully documented, and the description supplies the sibling routing and the downstream chaining hint. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% and all three parameters carry detailed descriptions, including page-depth limits and the perPage clamp, so the baseline is 3. The description only implies that `term` is a fuzzy partial match; it adds no syntax or format detail the schema doesn't already supply.

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/browse AniList's animation/production studios by name') and immediately distinguishes itself from get_studio by framing the use case as seeing multiple candidates rather than resolving a single closest match. An agent can tell the two apart without opening either schema.

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

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

Gives an explicit when-to-use ('when you want to see multiple candidates rather than take the closest match') and names the alternative, get_studio, along with the fact that its `name` param already does the same fuzzy resolution. This is exactly the routing information an agent needs between two overlapping search 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?

With readOnlyHint=true and openWorldHint=true already present, the description adds useful behavioral context: it returns AniList thread IDs plus title/category and is intended as a lookup step before get/post tools. It does not cover rate limits or auth needs, but it does not contradict the annotations and adds practical result-handling context.

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

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

The definition is two compact sentences, front-loaded with the core search/browse behavior and followed by return/usage context. Every sentence contributes useful selection or follow-up information.

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

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

Given the full schema coverage, existing output schema, and read-only/open-world annotations, the description supplies everything an agent needs at a high level: what is searched, how browsing works, what is returned, and which tools consume the results.

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

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

Schema description coverage is 100%, so all five parameters are already fully documented. The description restates the high-level filtering model (title/body text and/or category), but adds little syntax or edge-case detail beyond what the schema already provides.

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 specific verbs (Search/browse) and a specific resource (AniList forum threads), plus scope qualifiers (title/body text, category restriction). It also distinguishes the result from direct thread retrieval by saying the returned IDs are meant for get_thread, get_thread_comments, post_thread, or post_thread_comment.

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 clearly explains that omitting the term browses threads and that returned IDs feed specific follow-up tools, which gives strong usage context. It does not explicitly state when not to use this tool versus siblings like get_thread, but the path from search to retrieval is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-lookup behavior are covered without the description. The description adds the useful fact that results are IDs usable elsewhere, but says nothing about matching semantics (partial vs exact username), empty-result behavior, or result count — details the schema only partly touches via perPage.

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, front-loaded with the core action, then the return-value/consumer mapping. No filler, no restatement of the title, and every clause carries new 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?

An output schema exists, annotations cover the read-only/open-world profile, and the schema fully documents all four parameters. The description supplies the one thing none of those structured fields can: which sibling tools consume the returned IDs. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100% and the parameter docs are unusually rich (page × perPage ceiling, perPage clamping at 50, includeDescription token trade-off). The description adds nothing about parameters, so the baseline 3 applies — the schema, not the description, is doing all the parameter work.

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 AniList for users by username") and immediately says what comes back: AniList user IDs. It distinguishes itself from get_user_profile/get_user_stats/get_user_list/toggle_follow_user by positioning itself as the ID-resolution step that feeds those siblings, which is exactly the distinction an agent needs.

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

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

The description explicitly routes the agent: use this to obtain user IDs, then pass them to one of four named downstream tools, which is a concrete when-to-use rule. It lacks an explicit negative case (e.g. "if you already have a user ID, call get_user_profile directly"), so it falls one step short of full 5-level 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?

Goes well beyond the annotations by disclosing the state-validation mechanism, that a bare code or a URL from a different login is rejected, and that the call fails when no login is in progress. This is exactly the operational context an agent needs for a non-idempotent, stateful auth step, and it does not contradict the declared hints.

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, front-loaded with the action, then the precondition, then the failure mode and recovery. Every clause carries operational value; nothing is restated from the title or schema.

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

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

The tool is a single-parameter stateful auth step with an output schema, so return values need not be described. Preconditions, failure behavior, input format, and recovery path are all covered, leaving no gap an agent would need to guess at.

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

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

Schema coverage is 100% and already documents redirect_url, but the description adds real meaning the schema does not: the whole URL rather than just the code, and the reason (state is checked against the login attempt). That rationale is what prevents the most likely invocation error.

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