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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral detail beyond that: it returns both outgoing and incoming links, each with a relationship type, and frames it as a traversal following a prior get_* call. No contradictions with annotations, and the added context is valuable without being excessive.

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 two sentences, with the first sentence front-loaded to state the core action and output, and the second giving a brief usage directive. Every word is useful, with no redundancy or repetition of schema/annotation content. This is a model of concise, structured description.

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 read-only graph traversal tool with an output schema, annotations, and a clear description, this is complete. It explains what it does, when to use it, and what it returns. The output schema presumably documents the specific response shape, so the description doesn't need to elaborate. No critical information 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 description coverage is 67%, with slug and locale already described. The domain parameter has an enum but no description; the description does not clarify its meaning beyond 'unit' and the schema's enum values. The description's mention of 'given a unit' aligns with slug/domain but doesn't add further semantic detail. Since the schema covers most parameters, a baseline of 3 is appropriate.

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 function: 'Traverse the knowledge graph' and specifies it returns neighbours (outgoing and incoming links) with relationship types. This distinguishes it from sibling get_* tools that fetch a single unit and search/list tools that find or enumerate units. The verb 'traverse' plus the explicit output details make the purpose unambiguous.

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 explicit usage context: 'Use this after a `get_*` call to widen an answer with adjacent units.' This tells the agent when to invoke it, but it doesn't explicitly mention alternatives or when not to use it. Since the sibling tools are clear from the description, the guidance is adequate but could be more exclusionary.

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