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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds substantial behavioral detail beyond those: blastRadiusTotalCount is distinct-symbol count rather than row count, blastRadiusTruncated and blastRadiusTotalAtLeast describe sampling/bounds, and the explicit warning 'Never report the number of listed rows as the impact size' is a critical agent-facing caveat. It also discloses cost behavior for minimal and per-kind parameter effects.

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?

Although long, the description is information-dense and organized by kind with terse, purposeful clauses. Every sentence adds operational guidance, and the high complexity of a 24-parameter graph traversal tool justifies the length. The front-loaded purpose statement and scannable kind list make the structure effective.

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?

Despite having 24 parameters and no output schema, the description covers per-kind behavior, defaults, truncation semantics, cross-repo behavior, confidence/package row details, fallback guidance, and error reasons. It addresses the most dangerous misinterpretation of blast_radius results directly. For this tool's complexity, the description is remarkably complete on its own.

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%, so the baseline is 3, but the description adds real semantic value beyond the schema: it clarifies that blastRadiusTotalCount is not the row count, that expansionLimit caps the array, that includeCrossRepo defaults differ by kind, and that minimal:true is ~50% cheaper. These details are not inferable from the schema alone, so the description earns above 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 opening line 'Graph relationship traversal via one kind (real edges, not text)' names a specific verb, resource, and scope, and directly distinguishes graph edges from text search. The per-kind breakdown (callers, dependencies, blast_radius, heritage, chain, path) makes the tool's role concrete. It also names locate as the text-based alternative, which further disambiguates it from siblings.

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 clear usage context for each kind and explicitly says '0 results: call locate (mode:text), not Grep', providing a concrete when-to-use/alternative rule. It also explains edge-case semantics like includeCrossRepo defaults and blast_radius truncation. It does not explicitly contrast the tool with non-text graph siblings such as ref or diff_impact, so it stops short of complete sibling differentiation.

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