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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: matching is by term, alias, or a 'close contains-match', which tells the agent to expect fuzzy results. It says nothing about what happens on no match or the shape of the returned entry.

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 with the core purpose front-loaded, then the matching note. The parenthetical example list is long but earns its place by scoping the domain. 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 one-parameter, read-only lookup with no output schema, the description covers purpose, domain, and input matching. The only real gap is the no-match/empty-result behavior, which matters because 'contains-match' implies possible misses or false positives.

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 only says 'The term to define.' The description adds meaning by stating that aliases and partial/close matches are accepted inputs, which directly informs what string the agent should pass. That is real added value above the schema's baseline.

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 gives a specific verb-and-resource ('Plain-English definition of a court reporting or deposition term') and anchors the domain with concrete examples (appearance fee, errata sheet, stenotype, 30(b)(6)). It is clearly distinguishable from generic siblings like wrs_search or wrs_get_guide 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?

It implies when the tool applies (a terminology lookup) and describes the matching modes, but never states when NOT to use it or names an alternative such as wrs_search for broader queries. Usage is inferable rather than prescribed.

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