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

No annotations are provided, so the description carries the full burden. It discloses stable sense IDs, source provenance, and detailed budget behavior: independent detail limits, fair sharing across senses, 0 disabling a detail class, and truncated fields being listed on each sense. This provides substantial behavioral transparency beyond a simple lookup message.

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 compact, front-loads the core purpose, and uses every sentence productively. It covers return contents, language tag usage, limit semantics, and truncation behavior without fluff.

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 no annotations, seven parameters, and an output schema, the description covers the core invocation needs: required word, language, limit, and detail budget behavior. The main remaining gap is the undocumented part_of_speech parameter and the lack of explicit sibling differentiation, but an agent can still invoke the tool correctly for standard lookups.

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 86%, so most parameters are already documented. The description adds valuable semantics by clarifying that limit is the number of senses and that detail limits are independent total budgets fairly shared across senses. It does not clarify the part_of_speech parameter's filtering semantics, so it stops short of 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: 'Look up distinct dictionary senses for a word.' It enumerates returned content such as glosses, examples, IPA, etymology, and translations, which clearly distinguishes it from siblings like dictionary_synonyms or dictionary_translate even without naming 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 intended use is implied by 'Look up distinct dictionary senses' and the return list, but the description never explicitly says when to choose this tool versus dictionary_synonyms, dictionary_translate, dictionary_relations, or other siblings. There is no when-not-to-use guidance or alternative 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses relation_scope values, distance semantics, transitive behavior with sourced edges, provenance reporting, and the relationship between max_depth, transitive_limit, and limit. This gives the agent an accurate model of how the tool behaves.

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 dense but every sentence earns its place. It front-loads the core purpose, then explains direct vs transitive behavior, then defines the two non-obvious parameters. The structure is logical and avoids 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?

Given the tool's complexity—8 parameters, 11 relation enum values, and an output schema—the description provides enough detail to invoke it correctly. It covers the non-obvious relation scoping, distance behavior, and allocation rules, while return-value details are presumably handled by the output schema.

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

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

Schema coverage is only 50%, so the description must compensate for undocumented parameters. It adds real meaning by explaining max_depth as a graph hop limit, transitive_limit as a candidate-class allocation, and the allocation constraint with limit. It does not add detail for sense_id, but the description's treatment of the trickiest parameters is strong.

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: 'Find one directed lexical or commonsense relation.' It enumerates the full supported relation set and clarifies that results include direction and provenance, making the tool's purpose concrete. This distinguishes it from sibling lookup tools like dictionary_lookup or dictionary_semantic_neighbors.

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 clear within-tool usage context, especially around max_depth and transitive_limit: 'Set max_depth=1 or transitive_limit=0 for direct results only.' It does not explicitly name sibling tools or say when not to use this tool, but the supported relation list and direct/transitive distinction imply appropriate usage well enough.

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 the full behavioral disclosure burden and does so well. It reveals that the tool depends on an installed memory-mapped Numberbatch ANN index, returns an empty unavailable response when artifacts are missing, and returns finite cosine similarity in the range -1 through 1. These are genuinely useful operational details beyond minimal expectations.

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 compact and well-structured: a purpose-led opening, a dependency note, parameter behavior, and output semantics. Each sentence earns its place without redundancy, and critical information is front-loaded.

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

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

Given that an output schema exists and the annotation set is empty, the description covers the key operational caveat (unavailable artifacts), the language-filter behavior, and the similarity semantics. The agent has enough context to invoke the tool correctly and interpret its 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?

The description adds meaningful parameter semantics beyond the schema, especially for target_language and min_similarity, by explaining global, monolingual, and cross-lingual modes and the similarity range. Some parameters like limit and source_language still rely mostly on schema descriptions, but the schema already covers their defaults and constraints reasonably 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?

The description opens with a clear verb and resource: 'Find distributional semantic neighbours with an optional language filter.' This precisely identifies the tool's function and its distinguishing use of a Numberbatch ANN index. It does not explicitly contrast itself with siblings like dictionary_synonyms or dictionary_relations, so it falls just short of full differentiation.

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 concrete usage guidance for the language filter: omit target_language for global multilingual results, set it equal to source_language for monolingual results, or use a different tag for cross-lingual results. This is clear and actionable, though it does not explicitly state when to choose this tool over sibling tools.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It explains how max_senses and unsensed_limit interact, that unsensed candidates are grouped separately, that allocations must not exceed limit, and what count and candidate_count represent.

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 is front-loaded and every subsequent sentence contributes a distinct piece of behavior or result semantics. No filler or 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?

Given a 7-parameter tool with no annotations, the description covers the important parameter interactions and output counts, and the output schema can supply the remaining return-value details. Nothing essential for a correct call is missing.

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

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

The description adds meaning beyond the schema, especially for sense_id and part_of_speech that lack schema descriptions, and for unsensed_limit and max_senses with richer allocation semantics than the schema's short 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 first sentence uses a precise verb and resource: 'Find synonyms grouped by sense and part of speech.' This clearly separates dictionary_synonyms from siblings like dictionary_relations, dictionary_translate, and rhymes, and the grouping detail adds specificity beyond the name.

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 actionable context: pass a sense_id from dictionary_lookup when context matters, and unsensed results are only returned as explicit groups, with unsensed_limit=0 for strictly sense-scoped candidates. It does not explicitly compare against all sibling tools, but the context for how to invoke this tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It reveals that results are grouped by source sense, that senses are never silently crossed, that max_senses and limit operate independently, and that count and candidate_count report distinct nested result counts.

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 compact and front-loaded: purpose first, usage guidance second, then parameter semantics. Every sentence adds information that is not obvious from the schema, with no filler or repetition.

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

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

For a 7-parameter tool with no annotations and an output schema, the description covers the non-obvious behavior thoroughly: sense preservation, result grouping, budget semantics, and count meanings. The only omitted items, such as exact output shape, are already handled by the output schema, so nothing critical 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 71%, so the description does not need to re-explain every parameter. It adds meaningful semantics for the most confusing parameters: max_senses bounds inspected senses independently, limit is the shared translation-candidate budget, and sense_id comes from a prior dictionary_lookup call. This goes beyond the bare 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 opens with a specific verb and resource: 'Translate a word while preserving its source-sense association.' This clearly differentiates it from sibling lookup, synonym, relation, and rhyme tools, and it names dictionary_lookup as the complementary tool for ambiguous words.

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

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

It explicitly instructs the agent to 'Use dictionary_lookup first for ambiguous words, then pass its sense_id,' giving a concrete when-to-use alternative. It also explains how limit and max_senses should be set relative to one another, which guides parameter choices.

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 the full burden, and it delivers meaningful behavior: near means exactly one ARPAbet-token insertion, deletion, or substitution; there is no configurable edit distance; the query is excluded from results. This makes the tool's matching behavior predictable without overclaiming.

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

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

Every sentence earns its place: the core purpose, data source, near-mode definition, fixity of edit-distance behavior, and query exclusion are all stated in five short sentences. There is no filler or 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 description is self-contained for a read-only lookup tool: it explains source, matching semantics, fixity of behavior, and exclusion of the query. The input schema already documents normalization and limit constraints, and an output schema exists, so return-value details are not required here.

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 covers text and limit but leaves mode undocumented. The description compensates by defining near precisely and clarifying exact versus near behavior. It also adds CMUdict context that helps interpret text as an English lookup term rather than a free-form phrase.

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 exact or near English rhymes." It goes beyond a generic statement by specifying CMUdict-backed headwords, which clearly distinguishes rhymes from dictionary lookup, synonyms, and semantic-neighbor 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 usage intent is implied clearly by the tool name and opening sentence, and the near-mode edit-distance definition gives useful decision context. However, it never explicitly states when to prefer this over sibling tools like dictionary_semantic_neighbors or wordplay, nor does it provide when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it explains corpus backing, exact matching criteria, the context-only-for-pun rule, the contextualized/uncontextualized labeling, the 'never jokes' boundary, and provenance on every result. This is far beyond minimal 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 dense but every sentence adds necessary information, and the main purpose is front-loaded. The structured enumeration of kinds keeps complex detail readable without wasted words.

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

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

For a tool with 4 parameters, 2 required, and a rich output schema, the description provides all needed invocation context: required parameters, supported kinds, per-kind constraints, context handling, and provenance behavior. Nothing essential is missing for correct use.

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 gives each enum value a precise operational meaning (anagram normalization, palindrome storage status, spoonerism structure, CMUdict homophone puns) and explains the context parameter's special behavior. This substantially compensates for the schema's incomplete parameter 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 first sentence names a specific verb and resource: 'Find corpus-backed wordplay candidates of one requested kind.' The description then enumerates four distinct relation types, which clearly differentiates this tool from dictionary/rhyme siblings.

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

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

The description makes it clear when this tool is appropriate by tying each wordplay relation to a specific kind value. It does not explicitly name alternatives or state when not to use the tool, but the context is unambiguous enough for an agent to choose correctly.

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