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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: the three-valued routing outcome (resolved | ambiguous | needs_review), canonical URLs in the response, and the side effect that unmatched asks are logged as coverage-gap signals. It omits any auth or rate-limit detail, and the coverage-gap logging sits in mild tension with readOnlyHint even though it is telemetry rather than data mutation.

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?

Three sentences, each carrying distinct load: routing target, return semantics plus the route-not-answer boundary, then the coverage-gap side effect. The first sentence is dense with an enumerated list, but the critical disambiguation is front-loaded and nothing is redundant.

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?

With no output schema, the description carries the return-value burden and does so: confidence-ordered decision, the three status values, and canonical URLs. The single input is fully documented and the side effect is disclosed, so an agent has everything needed to call and interpret it.

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?

There is a single parameter whose schema description already covers it at 100% (free-text information need, with a concrete example and a 500-char cap). The description restates 'free-text GI ask' without adding format, length, or content constraints beyond the schema, so the baseline of 3 applies.

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?

Names a specific verb (route) and resource (free-text GI ask), and enumerates the exact target object types it can resolve to (claim, module, instrument, atlas region, prep-timeline, relationship). The boundary statement 'it routes, it does not answer' separates it cleanly from sibling resolvers like resolve_gi_claim and from answering tools like read_module.

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 clear context for when to use it (an unstructured user ask that must be mapped to a corpus object) and an implicit exclusion ('it does not answer'). It never names a sibling alternative such as resolve_gi_claim for the case where the ask is already a known claim, so an agent must infer the routing-vs-resolving split.

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