ccg_impact

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

No annotations are provided, so the description carries the full behavioral burden. It discloses directionality (incoming only), which is genuinely useful, but says nothing about read-only nature, depth/limit behavior, result shape, or truncation — all relevant for a traversal tool with a default depth of 2 and limit of 80.

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 telegraphic fragments with no filler and the key concept ('incoming') front-loaded. But the extreme terseness tips into under-specification — the fragments read as notes rather than a usable instruction, so concision comes at the cost of clarity.

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 3-parameter traversal tool with no annotations and no output schema, the description is too thin: an agent cannot infer what depth/limit control, whether results are capped, or what the returned structure looks 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%, so the description must compensate for all three parameters. It partially explains the query forms (bare symbol, file:…, *.h glob), but depth and limit are never mentioned, and the file:… syntax is left cryptic.

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 operation — incoming dependency/impact analysis — and maps the two input kinds to their results (symbols → callers, files → importers via #include). That is enough to distinguish it from an outgoing tool, but it never names or differentiates itself from the sibling ccg_callers, which appears to overlap.

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 'Symbols: … Files: …' fragments implicitly tell the agent which query form yields which result, which is real usage guidance. However, there is no statement of when to prefer this over ccg_callers, ccg_callees, or ccg_explore, and no prerequisites or exclusions.

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