define

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well by disclosing the return format (structured word_info, found:false) and error behavior (raises ValueError), which are behavioral traits beyond what the schema states. It misses minor details like rate limits or side effects, but for a read-only lookup tool, it is quite 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. It front-loads the main purpose, then returns details and error handling in separate sentences. Every sentence provides value, with no filler. It is appropriately sized for its 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?

Given the tool's complexity (2 params, simple lookup, error handling), the description is fairly complete. It covers the return format, failure case, and an error condition that requires calling a sibling. It doesn't explain the output structure in detail, but no output schema exists, so a bit more detail on the return structure might be expected. However, it names the fields (definitions, examples, IPA, audio URL, verb forms), which is sufficient for most agents.

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

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

Schema description coverage is 0%, so the description must compensate for parameter semantics. The description mentions 'unsupported language key' for the language parameter, implying it should be a valid language key, and implies the word is the lookup term. It adds semantic context, but doesn't detail the language key format or provide a list of valid values. Given the low coverage, this is adequate compensation.

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 purpose: 'Look up a word in a monolingual dictionary.' It specifies the resource (dictionary) and the action (look up), which is clear and distinguishes it from the sibling 'languages' tool. However, it does not explicitly contrast itself with the sibling, so it loses a point for lack of sibling 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 implies usage by mentioning 'call languages() first' for language key validation, which hints at a prerequisite. However, it does not explicitly state when to use this tool vs alternatives or when not to use it, so it falls short of providing explicit usage guidelines.

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