Identify callers of a C++ symbol by searching incoming control edges in a coroutine-aware call graph. Supports limits and unresolved stubs.
Who calls / awaits this symbol (incoming control edges).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Symbol keyword (name or qualified_name fragment) | |
| show_unresolved | No | Include unresolved::* stubs |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about return format, ordering, pagination, the meaning of the limit parameter, or how unresolved stubs behave. The only behavioral hint is 'incoming control edges', which is more purpose than behavioral detail.
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?
A single sentence, front-loaded with the core query semantics. There is no wasted text, and the parenthetical clarifies directionality efficiently. It is appropriately sized for the tool's simple interface.
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?
The tool has three parameters, no annotations, and no output schema, so the description must carry significant context. It states the purpose but omits when to use it versus alternatives, what the result looks like, how limit is applied, and what show_unresolved affects. An agent would need to infer or experiment with the remaining behavior.
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 the required query parameter and show_unresolved documented but limit undocumented. The description adds no parameter meaning beyond the schema; it merely restates that the query refers to a symbol. It does not compensate for the missing limit description.
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 states a specific verb and resource: identifying callers/awaits of a symbol via incoming control edges. It clearly distinguishes itself from the sibling ccg_callees tool by specifying directionality. An agent can tell exactly what this tool returns without opening the schema.
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 implies when to use it (finding incoming edges), but it does not explicitly state alternatives or exclusions. It never mentions sibling tools like ccg_callees or ccg_query, so the agent must infer the contrast. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.