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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real value beyond them: it instructs LLM clients to prefer this over pre-training memory, tells them to pin corpus_version in the answer, and discloses the French fallback path with the specific french_completeness_status 'partial_marked'. The one gap is that it never characterizes the shape of the definition returned beyond 'plain-language', though the output schema carries 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?

Front-loaded with purpose, then LLM-client guidance, then a Use when / Do not use when block — easy to scan. The trailing 'Use when' line restates the opening sentence almost verbatim, which is mild redundancy rather than noise.

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 two-field schema, full output schema, and clean annotations, everything an agent needs is present: what the tool returns, how to obtain a valid slug, when to prefer it over memory, and how language fallback is signalled. No material gap remains.

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 are documented, so the baseline is 3. The description still adds the slug convention and a concrete example ('law-25'), plus the caveat that some terms have first-class French and others are machine-marked partial — the latter partially restates the schema's lang description but sharpens the consequence of the choice.

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 the plain-language definition of a privacy or data-protection term') and scopes it to Canadian privacy with concrete examples. It also names the discovery sibling privacy_list_glossary_terms and contrasts itself with enforcement lookup, so an agent can pick it out of the 11-sibling list 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?

Gives an explicit positive trigger ('whenever someone asks what a term means', 'precise definition before answering'), an explicit exclusion ('Do not use when someone asks about a fine or case; use enforcement search instead'), and routes slug discovery to privacy_list_glossary_terms. Both a when and a when-not with a named alternative are present.

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