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, yet it says nothing about recursion/cycle handling, whether results are truncated, cost of deep traversal, or that the operation is a pure read. Only the purpose-level semantics are conveyed.

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 compact sentence with the key concept ('影响面分析') front-loaded and no filler. It is efficient, though it is terse enough that it borders on under-specification for a graph traversal tool.

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 return values need no explanation, but for a multi-parameter graph-traversal tool with zero annotation and zero schema-description coverage, the description leaves the agent without enough to predict traversal scope, cost, or depth 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 0%, so neither `fn` nor `max_depth` is documented anywhere. The phrase '按传播深度分层' hints that depth matters and `max_depth` defaults to 5, but the description never explicitly defines `fn` as the changed function source or explains what `max_depth` bounds.

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 verb+resource: which functions a change to `fn` propagates to, layered by propagation depth. That is meaningfully distinct from `who_calls`/`what_calls` (single-hop) and `call_path` (paths between two nodes), though the description never names those siblings to make the contrast explicit.

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?

No statement of when to use this instead of the closely related call-graph siblings `who_calls`, `what_calls`, or `call_path`, despite four overlapping tools in the sibling list. The 'impact analysis' framing only implies the use case; there are no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return behavior (array of the call chain, null when no path exists), which is useful, but it omits directionality (callers vs callees), how max_depth affects the search, behavior on cycles, and whether the search is exhaustive.

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?

Two tight sentences with the core action front-loaded and the return behavior following. It is efficient, though arguably too terse given the parameter gaps.

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 tool with zero schema coverage and no annotations, the description leaves the most important questions unanswered: what a and b identify, what max_depth does, and whether the path follows callers, callees, or both. The output schema covers the return shape, but the inputs remain opaque.

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%, and the description explains none of the three parameters. It implies a and b are path endpoints but never says whether they are entity IDs, names, or file paths, and max_depth is not mentioned at all.

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 verb and resource: find the shortest call path between a and b. An agent can tell it apart from list_entities or get_definition conceptually, but the description never names sibling tools like blast_radius or who_calls, so no explicit differentiation.

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?

No guidance on when to use this versus alternatives such as who_calls, what_calls, or blast_radius, and no mention of required preconditions (e.g. that a and b must already be indexed entities). The only usage hint is the implicit from/to framing.

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

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 what is returned (CIDs, checkers, severity, location, description), which usefully implies a read-only query, but it does not state safety profile, permissions, or result limits.

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 front-loaded sentence with a compact parenthetical enumeration of returned fields. Efficient, with no wasted prose.

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 single-parameter query tool with an output schema present, the description is largely adequate. However, it omits the file path format and gives no indication of result volume or ordering, leaving a minor gap.

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% and the single 'file' parameter has no format guidance (absolute vs relative path, expected extension). The description only restates '指定文件', adding essentially nothing beyond the parameter name.

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 verb (查询/query), resource (Coverity 静态分析缺陷), and scope (指定文件), plus the fields surfaced (CID/checker/严重级/位置/描述). It is clearly distinct from the call-graph/entity siblings, though it does not explicitly differentiate itself by name.

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 guidance on when to use this tool versus the sibling tools, and no prerequisites or preconditions are stated. The usage is only implicitly inferable from the purpose statement.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses an index-time dependency, but says nothing about what happens when the precondition fails, whether the call is read-only, or how large the payload may be.

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?

Two short sentences, front-loaded with the purpose before the prerequisite. Nothing is padded, though the brevity leaves the gaps noted above.

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 output schema covers the return value and there is only one parameter, so the bar is moderate. Still missing is any indication of the `fn` format or failure behavior for a tool whose main risk is not having the AST exported.

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 0% and the description never explains the single `fn` parameter — not its expected format (qualified name, signature, id), nor how to obtain a valid value from list_entities or search_entities. '函数级' only echoes that the argument is a function.

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 verb and resource: get a function-level AST, and even names the serialization format (CodeXM model JSON). It is distinguishable from siblings like get_definition or who_calls by the AST output, though it never explicitly contrasts itself with them.

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?

It gives a prerequisite — the function AST must have been exported during indexing — which implies this is only usable for already-indexed functions. It never says when to choose it over get_definition or another sibling, and offers no explicit exclusions.

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

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

No annotations exist, so the description carries the full burden; it mentions the returned location and entity info but says nothing about behavior when the symbol is unresolved, whether multiple definitions/overloads are returned, whether an index or workspace must be loaded, or the cost of the call. An output schema covers the returned fields, but the operational edge cases remain undisclosed.

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 short sentence with the resource and return payload front-loaded, no filler. It is efficient, though the terseness contributes to the missing guidance rather than compensating for it.

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 is simple (one required param, output schema present), so the description covers the essentials of what comes back. It is still incomplete on the inputs an agent must supply and on unresolved-symbol behavior, which matter for a lookup that can legitimately fail.

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% and the single required parameter 'name' has no documented meaning. The description only obliquely implies it is a symbol name via '符号', leaving format (fully-qualified vs simple), case sensitivity, and namespace/module qualification unaddressed.

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 verb+resource ('获取符号的定义位置') and even the return shape (文件:行号 plus entity info), so an agent knows exactly what it produces. It does not name or contrast any sibling such as search_entities or get_ast, so differentiation is left to inference.

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 explicit when-to-use, when-not-to-use, or alternative routing. The presence of search_entities, get_ast and list_entities among siblings means an agent must guess that this is for resolving an already-known symbol name, which is only implied.

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

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

No annotations exist, so the description carries the full burden; it discloses that results are ordered by line number, which is genuine behavioral information. It says nothing about behavior for a missing/unparsable file, whether nested or imported entities are included, or the size of the result for large files.

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 front-loaded sentence with the action and resource first and the ordering guarantee last. The parenthetical entity list earns its place by defining scope; nothing is redundant.

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?

This is a simple one-parameter read tool and an output schema exists, so return-shape explanation is unnecessary. The only missing piece is the file-path convention and error behavior, which a single clause would fix.

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 'file' parameter, so the description must compensate and only partly does—'源文件' tells the agent the path must point at a source file, but not whether it is absolute, workspace-relative, or repo-rooted. That is the one detail most likely to cause a failed call.

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 verb and resource (列出...实体) scoped to a single source file, and enumerates the entity kinds it covers (函数/变量/类型). It implies but never states the contrast with search_entities, so an agent must infer which of the two to pick.

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 '指定源文件中' implies 'use this when you already know the file and want everything in it,' which indirectly separates it from search_entities. No explicit when-to-use/when-not-to-use statement or alternative is named.

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

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

No annotations exist, so the description carries the disclosure burden alone. It states the return payload (TUs plus their full compile parameters), but says nothing about read-only semantics, cost or scale on large build graphs, or whether results are scoped to the current project. Adequate, not rich.

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?

Two sentences, both front-loaded with the core fact followed by the motivating question. No filler, no restatement of the tool name.

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 an output schema present and no parameters, the description only needs to convey scope, which it does. The one remaining gap is whether "actually compiled" means the whole project or the agent's current working context, and there is no note on result size.

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?

The schema declares zero parameters, so there is nothing to disambiguate; the description correctly gives no parameter guidance. Baseline 4 applies.

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 gives a specific verb and resource ("列出…翻译单元（TU）及其完整编译参数") and pins down what counts as a TU — one that actually participates in compilation. This distinguishes it in substance from list_entities, but it never names or contrasts with that sibling, so the differentiation is left implicit.

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 framing question "回答'哪些文件真正被编译了'" tells the agent the exact situation this tool serves, which is clear usage context. It stops short of exclusions or naming an alternative (e.g., when list_entities is the better pick), so no 5.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the FTS5 mechanism and fuzzy matching, but says nothing about read-only status, result ordering, limit behavior, or any permission/rate-limit considerations.

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 description is a single front-loaded sentence with a useful example and no wasted text. It immediately communicates the essential matching semantics.

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 return values need not be described. However, for a two-parameter search tool with no annotations and zero schema description coverage, the description is only minimally complete: query syntax is illustrated, but limit and result behavior are not addressed.

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 both parameters. It partially explains the query parameter via the fuzzy/FTS5 example and wildcard syntax, but the limit parameter is entirely undocumented in both schema and 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 clearly states a specific verb and resource: fuzzy search for symbols by name, backed by FTS5 full-text search, with an example query pattern. It does not explicitly contrast with sibling tools such as list_entities, but the 'fuzzy by name' scope is reasonably distinguishable.

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?

Usage is implied by the name-based fuzzy search and the example wildcard pattern, but there is no explicit guidance on when to choose this over list_entities or get_definition. No exclusions or alternatives are provided.

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

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 lists returned metrics but does not state that the operation is read-only, whether it has side effects, permission requirements, or freshness guarantees.

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 front-loaded sentence that identifies the status resource and its returned fields. It is appropriately sized with no redundant wording.

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 zero parameters, an output schema, and 100% schema description coverage, the description is sufficient to understand the tool's scope. It covers the returned metric categories but does not add behavioral context such as read-only guarantees or freshness.

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?

The tool has zero parameters, so parameter semantics are not applicable and the baseline is 4. There is no parameter information to add or omit.

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 clearly states the resource and the exact metrics returned: TU/entity/call-edge/defect counts and build time. It is naturally distinguishable from sibling data-query tools, though it does not explicitly name alternatives.

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?

It says what status data is available but gives no guidance on when to call this tool versus the sibling query tools. There are no exclusions, prerequisites, or alternative-routing cues.

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

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, yet it only discloses edge direction. It says nothing about whether results are direct calls only or transitive, how the `fn` identifier is resolved (name vs. qualified name vs. symbol ID), or what happens when the symbol is unknown or ambiguous.

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 front-loaded sentence with no filler; the directional qualifier is placed where it does the most work. It is efficient, though its brevity contributes to the gaps in other dimensions.

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 presence of an output schema relieves the description of explaining return values, but with zero annotations and an entirely undocumented parameter, the definition still leaves the agent without the identifier format or result semantics needed to call it reliably.

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?

The single parameter `fn` has 0% schema description coverage, so the description must compensate and does not. It never clarifies whether `fn` expects a bare function name, a fully-qualified path, or an entity ID — the one detail an agent most needs to invoke this correctly.

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 verb+resource: querying which functions a given `fn` calls, and adds the directional qualifier "正向调用边" (forward call edge), which implicitly separates it from the reverse-direction sibling who_calls. It stops short of naming that sibling, so the differentiation must be inferred rather than read.

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?

Usage is only implied: the parenthetical "forward call edge" hints that this is the forward-direction counterpart to who_calls, but no explicit when-to-use / when-not guidance or alternative is named. An agent must know the sibling set to choose correctly.

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

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.