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

With no annotations, the description carries the full behavioral burden. It conveys the operation is analytical/non-mutating and clarifies the traversal is transitive, but says nothing about cost, latency, how the depth cap is honored, or the shape of the result set — gaps that remain unaddressed by either annotations or an output schema.

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 clauses with zero filler: the identity of the result is front-loaded, then the timing advice. Every word earns its place and nothing is repeated from the schema.

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 low-complexity, two-parameter read tool with no destructive behavior, the description covers what the tool produces and when to reach for it. It is slightly thin on what the returned caller list looks like, though with no output schema the omission is minor.

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% and both parameters are documented in the schema, so the baseline of 3 applies. The word 'transitive' loosely hints at the meaning of depth, but the description adds no format, default, or range detail beyond what the schema already states.

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?

It names a specific resource and scope — 'transitive callers of a symbol' — and labels the concept ('the blast radius'), which implicitly separates it from siblings like find_references or who_imports that return non-transitive results. An agent can tell what it gets back 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?

'Run BEFORE changing a signature or behavior' gives a concrete trigger condition that maps to a real workflow moment. It does not, however, name an alternative (e.g. find_references for direct callers) or state when this tool is unnecessary, so it stops short of full routing guidance.

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 carries the full burden. It does disclose the output shape (imports + signatures with line ranges, no bodies), which is valuable since no output schema exists. However, it says nothing about failure modes (missing/unreadable files), large-file behavior, or permissions, leaving real gaps for a no-annotation tool.

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: the output contract is front-loaded, and the usage cue follows. No filler and nothing 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?

For a low-complexity single-parameter read tool, the description covers what matters most: what the outline contains and when to invoke it. The absence of output schema makes the enumerated return content especially useful; only edge-case behavior is unaddressed.

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?

Single parameter with 100% schema coverage already documented as 'Repo-relative file path.' The description adds nothing about the path parameter, so the baseline 3 is appropriate when the schema does the heavy lifting.

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 resource (file outline) and precisely enumerates its contents: imports plus every signature with line ranges, explicitly excluding bodies. This distinguishes it from symbol-level tools like read_symbol, though it never names a sibling directly, so the differentiation is implicit rather than 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?

Gives clear context: 'Use before reading a file in full,' which establishes this as a cheap reconnaissance step preceding a token-expensive full read. It provides the when without naming alternatives or stating 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?

With no annotations, the description carries the full burden and does disclose matching semantics: word-boundary, case-sensitive, all reference kinds, and that results carry the enclosing symbol. It omits any note on result caps, performance, or the 300-item limit behavior, so it is good but not complete.

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 scope front-loaded and zero filler; the parenthetical efficiently enumerates reference kinds without padding.

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 2-param read tool with no output schema and no annotations, the description covers intent and result content partially but says nothing about the undocumented 'limit' parameter, result truncation, or pagination across a repo-wide search. Usable but leaves an agent guessing on scale-related 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 coverage is 50%. The description reinforces 'name' semantics (word-boundary, case-sensitive matching, which goes slightly beyond the schema's 'exact, case-sensitive'), but the 'limit' parameter is undocumented in both the schema and the description, leaving half the surface unexplained.

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 names a specific verb and resource: 'Every mention of an identifier repo-wide', and enumerates the reference kinds included (calls marked [call], types, variables, imports), which implicitly distinguishes it from siblings like who_imports (imports only) and find_symbol (declaration lookup). It stops short of explicitly naming which sibling to use instead, so 4 rather than 5.

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 purpose — an agent can infer this is for finding all usages of an identifier — but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., vs. find_symbol, who_imports, or analyze_impact). Adequate but with a clear gap.

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 carries the full burden, and it partially does so by disclosing the return shape ('file:line, signature and container'), which matters since no output schema exists. It does not state read-only status, permission needs, or behavior on ambiguous matches, leaving real gaps.

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, zero filler, with the core action and scope front-loaded before the return-value note.

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 simple read-only lookup with no annotations and no output schema, the description covers purpose, scope, and return shape adequately. It falls short only in not distinguishing itself from sibling retrieval tools or explaining the limit parameter.

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 75%, so kind, name, and exact are already documented, and the description adds nothing beyond the looser 'by name, repo-wide' framing. The undocumented 'limit' (bound 1-50, semantics never explained) is left entirely to the schema's numeric 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 ('Find'), resource ('a definition'), and scope ('by name, repo-wide'), plus what it returns. It is clearly distinguishable from read_symbol, but it never names or contrasts with the sibling, 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?

No when-to-use guidance, no exclusions, and no alternatives named, despite an obvious sibling set (semantic_search for fuzzy lookup, read_symbol for reading a known symbol, find_references for usages). The agent must guess which lookup tool applies.

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 must carry the behavioral load. It discloses the return content (full source) and the read-only nature implied by 'read', but says nothing about behavior when a symbol isn't found, when multiple matches exist beyond the index hint, or handling of binary/generated 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 that states the core value proposition (one symbol's full source) with the key contrast (no whole-file read). No filler.

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 read-only single-symbol extractor with fully documented parameters and no output schema, the definition covers what the tool returns and its efficiency benefit. Minor gaps remain around multi-match resolution and not-found behavior, but nothing critical 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 100%, so each of the three parameters (file, name, index) is already documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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 (read) and resource (ONE symbol: function/class/method) and clarifies it returns full source without loading the whole file. This is clear, but it doesn't differentiate from the closely related sibling find_symbol or file_skeleton, so an agent could confuse the two.

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 by the phrase 'without reading the whole file', which suggests using this instead of a full file read. There is no explicit guidance on when to choose this over find_symbol, file_skeleton, or semantic_search, and no stated 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?

With no annotations provided, the description carries the full burden. It covers ordering behavior (relevant vs newest) which is a useful trait, but says nothing about authentication needs, rate limits, whether notes are scoped to a project or user, or what happens with an empty result set. For a read tool with zero structured behavior hints, this is thin.

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 compact sentences with no filler. Ordering rules are front-loaded and the safe-argless note follows. Efficient for a simple two-parameter 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?

The description is short and the tool is simple, but with no annotations, no output schema, and only 50% schema coverage, the description should fill more gaps (permissions, scoping, return contents, limit default). It leaves the agent guessing about how the tool behaves beyond ordering.

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 50%, with `query` described in the schema but `limit` undocumented. The description explains the semantic effect of omitting query (get latest notes), which adds meaning beyond the schema. However, it doesn't explain the limit parameter's behavior or defaults.

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 the resource (saved project notes) and the ordering behavior, distinguishing it from save_note. The verb 'recall' is clear, though the description spends a word on ordering rather than explicitly stating 'retrieve'. Still clear enough that an agent knows what it does.

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 'Safe to call argless at task start' gives a clear implied usage context for calling without parameters. However, it doesn't explain when the query variant should be used vs alternatives like semantic_search, save_note, or other sibling tools. The guidance is present but narrow.

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 reveals the incremental-by-default behavior, which is useful, but for an expensive forced re-scan it says nothing about cost, duration, whether the call blocks, or whether it invalidates existing cached results.

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, zero padding, and the core action is front-loaded ahead of the parameter note. Every sentence earns its place.

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?

There is no output schema and no annotations, so the description should ideally cover what the re-scan affects (index state, other tools' results) and rough cost. It covers the action and the full flag but leaves the operational consequences unstated.

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 100%, so the schema already documents 'full' as a boolean meaning 'Rebuild everything (default: incremental).' The description restates this without adding format, default, or interaction details beyond the schema, which is the baseline-3 case.

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 ('re-scan') and resource ('the repository'), making the action clear. It lacks differentiation from siblings, though 'reindex' is fairly distinct in this set (save_note, repo_map, semantic_search) so the risk of confusion is low.

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 usage via 'Use full=true to rebuild the index from scratch,' which is a hint about when to choose full mode, but it never states when to call reindex at all versus relying on automatic indexing or other tools. No exclusions or alternatives are given.

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, so the description carries the full burden. It discloses that html=true writes an interactive architecture map and that the tool ranks files by import centrality, which is valuable behavioral context. It doesn't mention side effects of the default mode or rate limits, but the write behavior is covered.

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, front-loaded with the core output and usage instruction. Very little waste, though the phrasing is compact to the point of being terse.

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 read-only mapping tool with no output schema and full parameter coverage, the description provides enough to invoke correctly and understand the html side effect. It could be improved with a note on typical output size or performance considerations, but it is largely complete.

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 schema fully documents both parameters (html and limit). The description adds the html behavior (writes map.html) but doesn't add details for limit beyond what the schema provides. Baseline 3 is appropriate.

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?

Clearly states it produces a project map covering languages, symbol counts, and key files ranked by import centrality. Distinguishes itself from read-oriented siblings, though it could more explicitly differentiate from file_skeleton or find_symbol.

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?

Explicitly says 'Call FIRST to orient,' which gives clear usage priority. However, it doesn't mention when not to use it or name alternatives for deeper analysis.

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 does disclose one meaningful behavioral trait, cross-session persistence, and frames notes as short. It omits scope (per-project vs global), storage/indexing side effects, deduplication, and whether saving triggers anything downstream, which matters for an unannotated write tool.

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 that front-loads the verb and resource and uses a parenthetical to enumerate the covered note types. There is no filler and nothing to trim.

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 two-parameter tool with full schema coverage and no output schema, the description supplies the essential purpose plus the persistence rationale. It is nearly complete, with the only gap being call scope and any storage-side behavior a caller might need to anticipate.

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 100%, so both 'tags' and 'text' are already documented and the baseline is 3. The description adds only the qualitative sense of 'short' and examples of note content, but nothing about tag format, reuse, or why text is not a required field despite being the payload.

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 pairs a specific verb (save) with a specific resource (short project note) and clarifies the note's content domain with concrete examples (decision, gotcha, convention). The save-vs-recall split against the sibling recall_notes is implied by the verb, but no sibling is named explicitly, which keeps it just short of a 5.

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 signals the appropriate content to record and the reason to do so ('survives across sessions'), which implies when to use it. However, it never states when not to save, nor points to recall_notes for retrieval, leaving the usage boundary to inference.

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 burden. It discloses the useful behavioral fact that local embeddings are used with keyword fallback when offline, which is real operational context. However it omits whether the operation is read-only, whether results are paginated, or how relevance is ranked.

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 compact sentences with zero waste. The core purpose is front-loaded, and the mechanism/fallback note follows efficiently.

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 search tool with no output schema, the description covers purpose, when-to-use, and the meaningful operational detail (local embeddings, offline keyword fallback). It is nearly complete; only ranking or pagination behavior for the limit parameter is unaddressed.

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 67%; the schema documents 'query' and 'scope' but leaves 'limit' without a description. The description itself doesn't add parameter syntax beyond the query example, but the baseline for this coverage level is reasonable and the query example clarifies intended input. It could have documented limit semantics, so not a 5.

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 ('Find code/notes') with the defining mechanism ('BY MEANING') and an illustrative natural-language example. It implicitly distinguishes itself from siblings like find_symbol, which presumably match exact names – the description explicitly notes this tool handles the case 'when the exact name is unknown'.

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?

Gives a clear when-to-use signal: use it when the exact name is unknown, with a concrete example query. It doesn't explicitly name find_symbol as the alternative to use for known names, but the conditional phrasing effectively steers the agent.

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 carries the full burden. It usefully discloses a side effect: dashboard=true writes an HTML report and returns its path, which is behavior beyond the schema. However, it says nothing about permissions, cost, whether reads are non-destructive, or the shape of the returned counters.

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 no filler, and the core output is front-loaded followed by the conditional behavior. Slightly under-specified, but nothing is wasted.

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 zero-required-parameter stats tool with no output schema and no annotations, the description is adequate but thin. It does not describe the returned counters/token format, so an agent knows roughly what to expect but not the response structure.

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 schema already documents the single parameter. The description adds value beyond the schema by clarifying that dashboard=true not only writes the file but also returns its path, which the schema's terse 'Also write .codegraph/dashboard.html' does not mention.

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 the resource (usage counters and estimated tokens saved), which is distinct from the code-graph siblings, but it lacks a clear action verb and never explicitly frames this as a stats/reporting tool. An agent can infer the purpose but must do some work.

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 statement of when to use this tool versus alternatives, nor any prerequisites or context. The only condition given is the dashboard=true flag behavior, which is a parameter detail rather than usage guidance.

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 does add one meaningful trait — the results are 'direct dependents' only, implying no transitive closure — but says nothing about read-only semantics (obvious for a query), result limits, or ordering.

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 tight sentence with the subject and scope front-loaded and zero filler. It is efficient, though terseness shades into under-specification rather than maximal usefulness.

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 no output schema and no annotations, the description must stand alone; it adequately conveys the return payload (importing files) and the direct-only scope, but omits any guidance on when to prefer it over the related reference/impact tools.

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 100% for the single 'path' parameter, so the schema already defines the repo-relative input. The description adds no format, default, or resolution semantics beyond that, making the baseline 3 correct.

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 resource and result: 'Files that import a given module — its direct dependents.' An agent immediately knows what it gets back. It does not name the closely related siblings (find_references, analyze_impact) to distinguish itself, so it falls short of a 5.

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 when-to-use guidance, no prerequisites, and no routing to alternatives such as find_references or analyze_impact, which appear to overlap in this namespace. Usage can only be inferred from the one-line purpose.

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