who_calls

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

No annotations are provided, so the description has to carry the full behavioral burden. It does add real value by noting the edges are 'compiler-verified', signaling accuracy/completeness of resolution, but it is silent on whether indirect or dynamic calls are included, on result volume, and on lookup cost.

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?

One compact sentence, front-loaded with the action and the key qualifier 'compiler-verified reverse call edges'. There is no filler, and the parenthetical adds the most decision-relevant detail without lengthening the entry.

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?

An output schema exists, so the description needn't explain return values, and the direction of the relationship is unambiguous. However, for a tool with no annotations and a completely undocumented parameter, the omission of the expected fn identifier format leaves a real gap for correct invocation.

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% for the single required parameter fn, so the description must compensate. It only conveys the conceptual role of fn as the callee being searched; it gives no hint about the accepted identifier format (a plain name, a fully qualified name, or an entity id), which is the main ambiguity an agent faces when calling this tool.

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: query which functions call a given function fn, explicitly framed as reverse call edges. The phrase '反向调用边' (reverse call edge) directly distinguishes it from the forward-call sibling what_calls, so an agent can pick between them without opening either 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 phrase 'which functions call fn' implies the use case (finding callers), but the description never states when to prefer this over what_calls, blast_radius, or call_path, nor any exclusions or prerequisites. Usage is inferable from the name and reverse-edge framing rather than explicitly guided.

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