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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real operational context: depth capped at 2, results capped at 10, and explicitly which fields are withheld (public prose, aliases, external links, media). That last sentence is genuinely useful for setting output expectations. The 'bounded direct-record admission without recursive content certification' phrase adds some coverage caveat but is largely opaque jargon.

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 core purpose and the bounds are front-loaded, which is good, but the middle sentences ('bounded direct-record admission without recursive content certification', 'Identity evidence and uncertainty remain separate') are compressed jargon that costs the reader more than it conveys. Roughly a third of the text is low-yield.

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 and a 7-parameter signature, the description covers traversal bounds and omitted output fields, which is the most important part. It stops short of explaining lang behavior, how prop interacts with inverse/hierarchy, or what the returned relationship records look like.

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% across 7 parameters, so the description must compensate and only partly does. It implies the semantics of depth (max 2), limit (10 results), and the inverse/hierarchy flags via 'outgoing, inverse or hierarchy', but leaves prop, lang, and id unexplained and never says what values prop accepts.

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 names the resource (one Wikidata QID) and the operation (bounded outgoing, inverse or hierarchy relationship retrieval), which is specific enough to separate it from kg_entity (single-record detail) and kg_search (query-based discovery). It never names a sibling explicitly, so the differentiation is inferable rather than stated.

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?

There is no when-to-use guidance, no contrast with kg_entity or kg_lookup_entities, and no stated prerequisites. The agent must infer from the name and the word 'related' that this is the traversal tool rather than the detail tool.

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