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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explains underlying endpoint behavior (alias resolution, fuzzy/prefix matching, other_names lookup), auto-correction semantics, is_alias meaning, category meanings, post_count usage, and provider-specific quirks (AIBooru mirrors Danbooru, cross-compatibility). This greatly exceeds basic mutation/read safety disclosure.

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 but every sentence earns its place. It uses a compact example table, a clearly labeled Behavior list, and provider notes. It front-loads the core purpose and then layers details without redundancy.

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

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

The tool has no output schema, no parameter descriptions, and no annotations. The description compensates by explaining return values (canonical name, post_count, category, is_alias) and workflow integration, covering edge cases like aliases and non-English terms. This is complete for a tool of this complexity.

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

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

The schema has 0% description coverage, so the description must compensate. It richly explains the 'query' parameter (partial, non-English, misspelling, multi-word, no star needed) and partially explains 'provider' via examples (Danbooru default, AIBooru behavior, others). However, 'limit' is not explicitly described, and provider semantics are only given implicitly. Still, the high-value query guidance justifies a strong score.

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

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

The description opens with a specific verb+resource+result: 'Autocomplete a tag fragment against the booru tag index, returning the canonical tag name with its post count and category.' It clearly distinguishes from sibling search tools by positioning it as a pre-search normalization step ('before calling the search tools').

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

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

The description provides explicit when-to-use guidance with concrete examples (natural words, fragments, non-English terms, misspellings) and alternatives: 'for rule34/gelbooru/e621 search use search_prompts/search_posts once you've found the tag name here.' It also gives operational tips like avoiding trailing '*', allowing multi-word fragments, and preferring tags with post_count > 100.

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 no annotations, the description carries full burden. It discloses 'No network request is made' and 'idempotent re-cleaning,' which are useful behavioral details beyond the tool name. However, it does not describe the output format or any potential failure modes, so it is not maximally transparent.

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

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

The description is concise and well-structured: the first sentence states the purpose, the second gives the use case, and the final block explains the input format with examples. Every sentence adds value, and it is appropriately front-loaded with the core need-to-know information.

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

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

Given the tool's complexity (13 parameters, no output schema, no annotations), the description provides enough to invoke it correctly for the main use case: cleaning an existing tag list. However, it leaves many optional parameters unexplained and does not describe the return value or expected output format, making it incomplete for a full understanding.

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

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

The description extensively documents the `tag_string` parameter with format examples, which is critical since schema coverage is 0%. However, it does not explain the other 12 parameters (e.g., `background_mode`, `resolve_conflicts`), leaving their semantics largely to inference from names and defaults. The coverage is insufficient for a low-coverage schema.

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

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

The description clearly states the tool's function: 'Clean an already-known set of booru tags into a ready-to-use prompt.' It also distinguishes from siblings by specifying when to use it (when you already have a tag list) and referencing related tools like `search_posts` and `autocomplete_tags`.

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 usage guidance is provided: 'Use this when you already have a tag list... and only want the cleaned output.' It also gives a clear exclusion: 'Do NOT pass natural-language sentences... use `autocomplete_tags` to find the canonical form.' This directly tells the agent when to use this tool vs. alternatives.

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

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

The description provides substantial behavioral details beyond annotations: parallel aggregation of four data sources, graceful degradation when a wiki page is missing, and auto_resolve behavior with resolved_from reporting. These are concrete, non-obvious behaviors that aid an agent in predicting tool outcomes.

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 but well-structured with a bolded lead, numbered data sources, clear Args/Returns/Examples sections, and no fluff. Every sentence adds value, and the most important guidance ('RECOMMENDED FIRST CHOICE') is front-loaded.

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

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

For a complex aggregation tool, the description covers all key aspects: data sources, failure modes, auto-resolution, parameter details, return format, and examples. Since an output schema exists, the description need not enumerate return fields, but it goes beyond by explaining what 'resolved_from' means and how errors are formatted.

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

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

The input schema has zero descriptions for its four parameters, so the description carries the full burden. It thoroughly explains each parameter (tag, limit, response_format, auto_resolve) with types, defaults, and behavior, including special handling for spaces and non-English queries. This fully compensates for the schema gap.

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

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

The description states a specific verb ('returns') and resource ('complete character profile'), enumerating exactly what is included: visual traits, wiki description, multilingual aliases, and bidirectional tag implications. It is clearly differentiated from siblings by being labeled 'RECOMMENDED FIRST CHOICE' and 'Returns everything in one call.'

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 says 'RECOMMENDED FIRST CHOICE for any character/tag lookup' and gives examples of when to invoke it. However, it does not explicitly mention exclusions or direct alternatives (e.g., when to use a lighter-weight sibling like danbooru_lookup_tag), so it falls just short of a 5.

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

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

With annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral context: the directionality of implication (antecedent only), the meaning of A -> B, the validity of empty lists, and details on response formats and error strings. It goes well beyond what annotations provide and does not contradict them.

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 well-structured with intro, direction explanation, Args, Returns, and Examples. However, the antecedent-direction phrase is repeated nearly verbatim in two paragraphs, creating slight redundancy. Still, every sentence contributes functional value and the front-loaded purpose is clear.

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

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

Given the tool's moderate complexity (3 params, output schema present but not detailed), the description is complete: it clarifies directionality, provides contrasting alternatives, documents return formats and error handling, explains edge cases (empty list), and includes a worked example. No important aspect appears 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?

Since schema description coverage is 0%, the description fully compensates by explaining each parameter: tag with auto-underscore conversion, limit with range and default (1-1000, default 50), and response_format with allowed values ('markdown' or 'json'). It also gives real examples, turning the raw schema into actionable 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?

The description opens with a specific action: 'Get the implication chain for a tag (A -> B auto-adds)' and immediately scopes it to the antecedent direction. It also distinguishes itself from the sibling 'danbooru_get_character_profile' by explicitly naming it as the alternative for reverse lookups, making the tool's purpose unambiguous.

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

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

The description gives explicit when-to-use guidance: 'For character costume variants, use danbooru_get_character_profile which queries both directions. This tool queries only the antecedent direction' and repeats the reverse-direction alternative later. It also notes that an empty list is a valid result, which sets expectations for edge cases.

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?

While annotations already declare readOnly/idempotent/destructive false, the description adds meaningful behavioral context beyond those hints: it explains DText markup is converted to readable text, the body_limit truncation behavior, the response_format options, and exact error responses including 404 handling. This helps the agent predict tool behavior accurately.

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 well-structured with a clear opening purpose, a differentiation line, and labeled Args/Returns/Examples sections. Every sentence adds value: parameter details, error behavior, and usage examples are all necessary. Despite its length, it is appropriately sized for the tool's complexity.

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

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

The description is complete for a read-only lookup tool with one required parameter. It covers what the tool returns, how the parameters affect output, the error behavior, and provides two illustrative examples. Combined with the annotations, nothing essential is missing for correct selection and 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 input schema has no parameter descriptions (0% coverage), so the description carries the full burden. It explains 'title' with an example and the automatic underscore conversion, 'body_limit' with the 0=no-limit semantic and rationale, and 'response_format' with the two allowed values. This fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific action: 'Get the textual wiki description for a tag,' identifying the exact resource and verb. It further distinguishes itself from the sibling 'danbooru_get_character_profile' by explicitly stating this tool retrieves only the wiki page, not full character info.

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?

Provides explicit usage guidance: use 'danbooru_get_character_profile' instead for complete character info, and this tool for the canonical wiki description. It also gives concrete examples showing when to query a character title versus a general tag like 'ahoge', making selection against alternatives 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?

Beyond the readOnlyHint=true annotation, the description discloses internal behavior: it uses Danbooru's autocomplete endpoint for alias resolution and prefix matching, falls back to tags.json, and matches against other_names. This gives the agent deeper insight into how queries are handled. No contradiction with annotations.

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

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

The description is well-structured with clear sections: purpose, exclusions, implementation detail, args, returns, and examples. It is front-loaded with the core purpose and every sentence adds value, making it appropriately sized for the tool's complexity.

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

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

The description covers all 7 parameters, the return format (Markdown or JSON), error behavior, and gives practical examples. It also explains when to use this tool over siblings, making it sufficiently complete for a complex lookup utility.

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

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

With 0% schema description coverage, the description fully compensates by explaining all 7 parameters in detail: query semantics (wildcards, autocomplete, other_names), category values, limit range, order options, hide_empty, auto_resolve fallback, and response_format. This goes far beyond the bare schema types.

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

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

The description opens with a specific verb and resource: 'find or verify a tag's exact canonical name.' It explicitly distinguishes from sibling tools by stating 'NOT for character analysis' and naming the alternatives, making the purpose unmistakable.

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

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

The description clearly says when to use this tool (finding/verifying tags, listing variants) and when not to (character analysis), and it names the alternative tools. Examples such as 'amamiya_kokoro' and '*_blue_archive' provide concrete usage context.

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

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

Adds significant behavioral detail beyond the readOnly/idempotent annotations: describes probability interpretation (0.92 = 92% of posts), ordering by frequency, default exclusion of meta tags, auto_resolve with resolved_from reporting, and error format. There is no contradiction with annotations; it enriches them.

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?

Although longer than many descriptions, it is logically structured with headers and examples. Each sentence adds value: purpose, co-occurrence explanation, exclusions, auto_resolve behavior, parameter details, return format, and real examples. Nothing is redundant; the length is justified by the tool's complexity and zero schema coverage.

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 moderately complex tool with 7 parameters and multiple behaviors, the description covers all bases: return format (markdown/json), error message, auto-correction behavior, example queries, and relation to sibling tools. The output schema may exist, but the description still explains the string return, ensuring the agent knows how to interpret 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?

Input schema has 0% description coverage, but the description fully compensates. Every parameter is explained with types, defaults, and meaning: tag (canonical, spaces->underscores, autocomplete), limit (1-100, default 25), category (enum values), min_frequency (0-1, probability), exclude_meta (default True), response_format, and auto_resolve. This is exemplary parameter documentation.

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

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

The description opens with a specific verb+resource: 'Get visual trait frequencies for a character tag.' It then clearly distinguishes from sibling tools by declaring it the 'Best tool for character visual trait analysis' and suggesting danbooru_get_character_profile for wiki/implications. This makes the purpose unambiguous.

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

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

Explicitly states when to use this tool ('Best tool for character visual trait analysis') and names the alternative for a different need ('Use danbooru_get_character_profile if you also need wiki/implications'). Also explains behavior with auto_resolve for misspelled tags, giving concrete usage context.

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

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

With no annotations provided, the description carries full burden and does it thoroughly. It discloses the raw/uncleaned nature of results, AND-semantics for tags, provider-specific tag caps, error behavior on exceeding limits, and the structure of returned posts (tag_string, artist/character/copyright splits, optional URLs).

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 well-organized with a clear opening sentence and bulleted details. Every section adds value: search semantics, provider caps, autocomplete fallback, and post structure. Despite its length, it avoids redundancy and is appropriately scoped for a complex tool.

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

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

Given 9 parameters, no output schema, and no annotations, the description covers the essential behavior and enough output structure to set expectations. It lacks details about pagination or what happens with invalid tags, but overall it gives a solid mental model for invoking and interpreting 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 0%, so the description compensates for the most critical parameters: tags (syntax, AND behavior, single-tag preference, caps), provider (caps listed), and the boolean include_preview/include_file_url (via 'optionally preview/file URLs'). It does not explain page, limit, order, rating, or random_seed, but those are relatively self-explanatory with defaults and enums in the schema.

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

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

The description clearly states the tool searches a booru and returns the raw post list, with an explicit contrast to search_prompts. It distinguishes itself by emphasizing 'no cleaning' and by naming sibling tools like autocomplete_tags for concept resolution.

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?

Provides explicit guidance: 'Use this tool when you want to inspect the original tags before deciding how to process them.' It also gives alternative tool guidance ('call autocomplete_tags first') and explains multi-tag limits per provider, including env var workarounds.

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 no annotations, the description carries the full burden of disclosure. It explains non-obvious behavior: this is not keyword search, multi-tag queries are ANDed, providers cap plain tags, exceeding the limit returns an error, and the env var can raise the cap. It also discloses the return format with category splits. No contradiction with annotations exists.

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 but tightly organized with clear headings ('WHEN TO USE A DIFFERENT TOOL INSTEAD', 'SEARCH SEMANTICS') and every sentence contributes actionable guidance. The purpose is front-loaded in the first sentence, and no filler or redundant phrases appear.

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

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

Given the tool's complexity (17 parameters, 5 providers, no output schema or annotations), the description covers all essential invocation aspects: tag syntax, query semantics, provider-specific limits, alternatives, and return value shape. It even provides common starting-point tags, making it fully usable for an agent to select and 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?

The schema has 0% parameter descriptions, so the description must compensate. It thoroughly explains the critical `tags` parameter (underscore format, AND semantics, per-provider caps), `order` (order:rank, random), `provider` (the booru list), and rating metatags. However, several parameters (page, limit, exclude, optimize, background_mode, etc.) are left to their names alone, preventing a perfect score.

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

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

The description opens with a precise verb and resource: 'Search an image booru (Danbooru/AIBooru/e621/Gelbooru/Rule34) by TAG and return ready-to-use, cleaned AI-art prompts.' It also specifies the output shape (full prompt string plus category split), which clearly differentiates it from sibling tools like search_posts and build_prompt.

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?

An explicit 'WHEN TO USE A DIFFERENT TOOL INSTEAD' section names alternatives (danbooru_get_character_profile, autocomplete_tags) and explains exactly when they are preferable. The 'SEARCH SEMANTICS' section gives concrete usage rules: prefer a single tag, avoid natural-language queries, use underscores, and consult autocomplete_tags for uncertain spellings.

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