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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only that the result is a changed-file list (not diff content), which is mildly useful but says nothing about pagination, revision resolution, or error behavior.

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 efficient sentence with the action front-loaded. The trailing rationale clause is slightly abstract but not 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?

There is no output schema and no description of the return shape (path format, ordering, renames), and three undocumented parameters remain unexplained. For a tool with 0% schema coverage this leaves real gaps an agent must guess at.

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% across three parameters, so the description must carry the burden of explaining them and it does not. The words 'Git revision' loosely gesture at the 'revision' parameter, but 'entity' and 'repo_path' are entirely 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?

States a specific verb and resource: 'List files changed by a Git revision'. This is clearly a file-list producer rather than a diff viewer, but it never names siblings like git_diff or recent_changes, so distinction is only 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?

'as evidence for downstream impact reasoning' implies it is a feed for impact analysis, but no condition tells the agent when to pick this over git_diff or recent_changes, and no exclusions are stated.

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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description adds meaningful context beyond them: scanning happens 'from a disposable copy' (no repo mutation) and unconfigured scanners return an 'honest fallback' rather than silently failing. It omits runtime/rate characteristics and what a fallback report looks like.

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 dense sentence that front-loads the action and tooling with no filler. It is slightly packed with parenthetical definitions, but every clause 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?

With no output schema and no annotations gap, the description covers the operator-configuration model and safety posture, which is the key complexity. It still leaves parameter meaning and result shape unaddressed, so it is adequate rather than 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 description coverage is 0% for two parameters, yet the description never mentions repo_path or the timeout (and its 120s default). With no schema descriptions, the description was the only place to compensate for the coverage gap, and it does not.

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?

Names the concrete tooling (Semgrep SAST, Gitleaks secret detection) and the target (a repository), so the agent knows exactly what analysis runs. It stops short of distinguishing itself from close siblings like security_scan and vulnerability_scan, which likely also run scans.

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 prefer this over security_scan or vulnerability_scan, nor any prerequisites or exclusions. The note that sub-scanners are 'independently optional' hints at configurability but gives no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context beyond that: deterministic output, CycloneDX 1.6 format, and the explicit exclusion of vulnerability enrichment, which sets correct expectations about behavior and scope.

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 wasted words. It efficiently conveys the core purpose and scope limitation.

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 one-parameter, read-only, idempotent tool with no output schema, the description supplies the output standard, determinism, source scope, and an explicit exclusion. The main gap is the lack of detail about supported manifest/lockfile ecosystems, but an agent can still invoke it correctly with the required repo_path.

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 repo_path. The description only loosely contextualizes it by mentioning 'supported local manifests and lockfiles,' but does not clarify whether repo_path is a directory, which manifest/lockfile formats are supported, or any other constraints. This is insufficient compensation for the missing schema documentation.

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 (generate) and resource (CycloneDX 1.6 component inventory) with source scope (local manifests and lockfiles). The phrase 'no vulnerability enrichment' implicitly distinguishes it from vulnerability_scan and security_scan, but does not explicitly differentiate from overlap with software_inventory or other siblings.

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 by stating it performs no vulnerability enrichment, which suggests it is for inventory generation rather than security scanning. However, it gives no explicit when-to-use guidance, no prerequisites, and does not name alternative tools for related tasks.

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?

Annotations already declare the safe read-only, idempotent, non-destructive profile. The description adds real behavioral context beyond them: results are 'direct' (one hop, non-transitive) and bounded to the local index, meaning stale or incomplete coverage is possible. It still says nothing about truncation behavior with max_results, so a 3 is appropriate.

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 semicolon-separated scope caveat; no filler or restatement of the name. Dense and efficient, though it is brief enough that some useful detail is omitted rather than 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 four-parameter tool with 0% schema description coverage and no output schema, the description leaves the agent guessing on parameter values, repo_path semantics, and result truncation. Annotations cover safety, but they cannot fill the parameter gap that this terse description also fails to fill.

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 all four parameters. The description conveys that symbol and direction (callers vs callees) exist, but it never states the direction values ('out'/'in'), what repo_path must point at, or that max_results truncates results, so it does not compensate for the schema gap.

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) and resource (indexed symbol-reference edges) with scope (direct callers or callees), which lets an agent distinguish it from generic search tools like search_code or find_symbol. It does not name a sibling explicitly, so it stops 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?

The stated output (direct callers/callees) implies when the tool is relevant, and 'evidence is limited to the local index' is a useful usage caveat about incomplete results. However, there is no when-not guidance and no routing to alternatives like find_symbol or search_code, so guidance 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds a useful scope limitation (no vulnerability claims) but says nothing about output shape, what 'supported' manifests means, or how the inventory is structured, which would have added real behavioral value beyond the annotations.

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 pairs the positive scope with the negative boundary. No padding, nothing 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 one-parameter read-only tool this is close to adequate, but with no output schema the description should have described what the inventory returns (manifest names, versions, lockfile locations). The undefined term 'supported' also leaves coverage gaps.

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 never mentions repo_path or its expected form (path string, absolute vs relative, directory vs file). While the parameter name is fairly self-evident, the low coverage means the description should have compensated and does not.

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 (inventory) and resource (dependency manifests and lockfiles), and the trailing clause 'does not make vulnerability claims' carves out a boundary against the vulnerability_scan/security_scan siblings. It does not distinguish itself from siblings like cyclonedx_sbom, software_inventory, or dependency_graph, 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?

The phrase 'does not make vulnerability claims' implicitly signals when this tool is the wrong choice (vulnerability questions), which is better than nothing. But it never states when to prefer this tool, nor names the alternative to reach for, leaving usage 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds critical behavioral context: it runs in a disposable copy and returns evidence only, never executing arbitrary commands. This addresses safety and scope beyond annotations.

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 is front-loaded with the core action and constraints. Every phrase ('disposable copy', 'evidence only', 'never accepts arbitrary commands') earns its place without redundancy.

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 2 parameters, no output schema, and no schema descriptions. The description omits any parameter information and does not explain return values (though an output schema is absent). While it covers key behavioral aspects, it is incomplete for callers needing to know required inputs and expected results.

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?

With 0% schema description coverage, the description must fully explain parameters. It does not mention 'repo_path' or 'timeout' at all. The description only implies the tool operates on a project, but no parameter details, defaults, or usage are provided.

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 uses a specific verb ('Run') and a precise resource ('detected project-native diagnostics'). It clearly distinguishes itself from siblings like run_tests and security_scan by specifying 'disposable copy' and 'detected project-native'.

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 implicitly states when to use it: to obtain diagnostic evidence from project-native tools. But it does not explicitly name alternatives or when not to use it (e.g., when to use run_tests or security_scan instead). The context of a disposable copy suggests a safe, exploratory use case.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by stating the export is 'strict source-free' and 'never includes raw source,' which is useful for privacy and security decisions. It does not cover authentication, rate limits, or output structure, but it clearly exceeds the annotation baseline.

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 definition is a single front-loaded sentence with no filler. It communicates the main action, scope, and key constraint 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?

The tool is simple and read-only, and the description conveys what the exported map contains. However, it omits any explanation of the required repo_path parameter and does not describe the return format, which matters because there is no output schema.

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 has 0% description coverage for the single required parameter 'repo_path', and the description does not explain what the parameter should be or how it is interpreted. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema documentation.

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 uses a specific verb ('Export') and resource ('code map'), and it clarifies the map's contents (paths, hashes, symbols, graph edges) and the key constraint that it is source-free. It does not explicitly name a sibling alternative, but the purpose is clear.

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 guidance on when to use this tool versus alternatives such as ingest_code_map or map_status. The description only implies that a map must already be indexed, leaving the agent to infer the correct context.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered without the description. The only extra signal is the word 'indexed', which faintly implies a prior index_code step, but no explicit prerequisite, result limits, or scope behavior is disclosed.

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 tight sentence with the core action front-loaded and no filler. It is efficient, though its brevity is also the source of the missing detail.

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?

A search tool with three undocumented parameters, no output schema, no usage guidance, and only annotation-provided safety. Much more is needed for an agent to call it correctly versus its many siblings.

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 all three parameters, so the description carries the burden and fails to compensate. 'By name' loosely maps to the name parameter but gives no format (simple vs qualified name), and repo_path and max_results are entirely 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 states a clear verb (Find) and resource (indexed symbols) with scope (across all supported languages) and the matching key (by name). It does not, however, differentiate from close siblings such as lsp_symbols, map_find_symbol, or search_code, leaving the agent to guess which symbol-lookup tool applies.

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 stated prerequisite that an index must exist (despite 'indexed' implying it), and no mention of when to prefer this over lsp_symbols or map_find_symbol. The agent gets no routing information.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return shape (stat + patch), which matters since there is no output schema, but it omits diff size/truncation behavior.

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 essential purpose and output format are stated immediately.

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 0% schema description coverage, the description should say more about return content, large-diff handling, and the repo_path/commit parameters. It is adequate but leaves gaps for a git tool that can produce very large outputs.

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 carry parameter meaning. It does add that only a single commit is diffed (no ranges), but says nothing about the repo_path parameter or commit defaulting to HEAD. With 2 mostly self-evident parameters, this is partially compensating.

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?

"Show the stat-and-patch diff for a single Git commit" names a specific verb (show) and resource (diff of one commit) and the qualifier "single" distinguishes it from range- or repo-level tools like recent_changes or analyze_change. It is clear, though it does not explicitly name which sibling to prefer.

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 "as evidence for a specific change" implies the investigatory use case but gives no explicit when-to-use vs when-not conditions or named alternatives. Usage is inferable, not stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety and repeatability are covered. The description adds one genuinely useful fact beyond them: raw source is not persisted, so index-backed lookups will not surface file contents. It still omits where the index is stored, how expensive a build is, or what happens on a partial/failed index.

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, action first and the storage caveat second. Nothing is wasted and the lead clause front-loads the operation.

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?

Annotations cover the safety profile and there is no output schema to explain, so the bar is modest. However, for a tool that is the prerequisite for the map_* and symbol-lookup family, the description never states that dependency, prerequisites, or cost, leaving an agent to guess when it fits in a workflow.

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?

There is a single parameter (repo_path) with 0% schema description coverage, so the description carries the burden. 'For a repository' loosely maps the parameter to a repository target, but it gives no path format, relativity, or remote/URL guidance, leaving the only required argument underspecified.

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+resource pair: 'Build or update the local symbol map for a repository.' It is clearly distinguishable from read-only consumers like find_symbol or search_code. It stops short of explicitly naming which sibling tools depend on this index, so it is clear but not maximally differentiated.

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: nothing says this must run before map_find_symbol/map_dependency_graph, whether it is safe to re-run, or when it should be refreshed instead of supplemented by search_code. The agent must infer usage from the name alone.

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?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds useful context: validation happens before storage and the write is transactional. However, it doesn't say what 'source-free' means, what a validation failure looks like, or what happens to an existing code map for the same project.

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 efficient sentence front-loaded with the core action. No wasted words, though the density means details like 'source-free' go unexplained.

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 mutation tool that stores a nested-object payload with 0% schema coverage and no output schema, the description is too thin. It gives no insight into required payload structure, validation error behavior, or whether ingestion replaces or merges an existing map.

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 two parameters (project_id and a nested code_map object) are entirely undocumented. The description doesn't clarify the expected structure of the code_map payload or the format of project_id, leaving the agent to guess at a nested object schema.

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 pair (validate, store) and a specific resource (source-free code map) scoped to one tenant project. This is distinguishable from siblings like export_code_map or index_code, though it doesn't explicitly name those siblings.

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 or when-not-to-use guidance. The agent cannot tell from the description how this differs from index_code or when a code map should be ingested versus exported. No prerequisites or conditions are stated.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses that output is evidence only and explicitly that it will not assert a root cause, which shapes how the agent should treat the result. It still omits output format and pagination/breadth details, keeping it at a 4.

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 with zero filler: the first front-loads the purpose and evidence sources, the second front-loads the output contract. It is appropriately sized, though a brief clause clarifying scope or prerequisites could be added without bloat.

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 complex six-parameter aggregator with no output schema and 0% parameter description coverage, yet the description does not explain how question and repo_path drive the investigation, what each search parameter does, or what the returned evidence looks like structurally. Annotations cover safety, but the description leaves too much unspecified for an agent to invoke it confidently in edge cases.

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% across six parameters, so the schema itself adds no semantic help. The description's enumerated sources (commits+diffs, code search, log search, test results) only loosely hint at some parameters like since, search_query, log_path, and log_query, and it says nothing about repo_path, question, or formats such as the '30d' default for since. This is a substantial compensation gap for a 6-parameter 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 uses a specific verb ('Gathers evidence') and enumerates the exact resources collected (recent commits + diffs, code search, log search, test results), which clearly distinguishes it as an aggregator rather than a single-source tool like git_diff or search_logs. It stops short of explicitly stating how it relates to those individual siblings, so it earns a 4 rather than 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 frames the intended context ('relevant to an engineering question') and sets a clear output boundary ('returns evidence only ... reason over the returned evidence yourself'), which implicitly tells the agent when this broad evidence-gathering tool is appropriate. However, it never names alternatives or says when NOT to use it versus calling recent_changes, search_code, or search_logs directly, leaving usage guidance at an implied level.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds meaningful behavioral context by disclosing the categories of information returned (language mix, test files, parser backends, size, build ecosystems). It says nothing about performance on large repos, whether it recurses, or how deep the scan goes, so it stays at a moderate level.

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, and the verb and scope appear immediately. The trailing enumeration is slightly list-heavy but every item earns its place by telling the agent what the output contains.

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, the description carries the burden of describing returns, and it does so by naming the five inventory categories. Combined with one obvious required parameter and annotations covering the safety profile, an agent has enough to call it correctly; only alternative-tool routing is missing.

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 never mentions repo_path, so it does not compensate. However, the single parameter is a self-explanatory repository path with a matching title, making the semantic gap minimal in practice. This lands just above baseline.

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 ("Inventory") and enumerates the exact resources it reports on (languages, test files, parser backends, source size, build ecosystems), so the agent knows precisely what the tool produces. It does not, however, differentiate itself from closely related siblings like repo_overview, software_inventory, or dependency_graph, all of which also survey a repository.

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 stated condition for when to choose this tool over repo_overview or software_inventory, no prerequisites, and no exclusions. Usage is only inferable from the phrase "in a polyglot repository," which hints at multi-language codebases but stops short of 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the remaining burden is operational detail. The description adds only 'returns bounded symbol evidence only' — an unexplained size qualifier with no statement of what 'bounded' means (truncation? caps? pagination?) and no mention of the configured adapter's failure modes or language support.

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, which is appropriate for a simple lookup tool. It is efficient, though it spends its few words on jargon rather than the concrete facts an agent needs.

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 0% parameter coverage, the description must carry the full load, and it doesn't. It omits what symbols are returned, the meaning of 'bounded', and the semantics of all four parameters — significant gaps for a tool with this much undocumented 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 description coverage is 0% and all four properties carry no descriptive text, so the description is the only place semantics could be supplied. It says nothing about repo_path, file_path, language, or timeout, leaving every parameter undocumented in both places.

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 verb+resource ('structural symbol adapter') and a scope ('one repository file'), which is better than a tautology. But 'operator-configured structural symbol adapter' is jargon that doesn't concretely say what the tool extracts (symbols like functions/classes), and the description never distinguishes it from the sibling 'find_symbol' or 'map_find_symbol', which plausibly do the same job. An agent cannot route confidently between them from this text.

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 when-not-to-use, and no mention of alternatives. The sibling list contains at least three symbol-related tools (find_symbol, map_find_symbol, lsp_symbols) and the description gives nothing to choose between them, leaving selection entirely 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the key context that the map is 'hosted' and 'source-free', but says nothing about permissions, return format, or pagination behavior.

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 zero waste. It efficiently communicates the core purpose without unnecessary detail.

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 tool with 4 parameters (two required), 0% schema description coverage, no output schema, and multiple similar siblings, the description is inadequate. It lacks parameter guidance, usage context, and differentiation from alternative 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 0%, so all four parameters (symbol, direction, project_id, max_results) are undocumented in both schema and description. The description mentions 'callers or callees', which hints at the direction parameter, but does not explain default values, valid direction strings, or required project_id.

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 action (query callers or callees) and resource (hosted source-free code map), which is clearer than a tautology. However, it does not distinguish this tool from siblings like dependency_graph or find_symbol, leaving an agent uncertain about which to choose.

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 indication of when to use this tool versus alternatives such as dependency_graph or find_symbol. The description only implies usage through its verb, providing no exclusions or context for selection.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by noting it operates on a hosted source-free map without requiring checkout access, but it does not cover permissions, rate limits, or return format.

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 gets to the verb and resource immediately. It is efficient, though its extreme brevity may be a missed opportunity rather than a structural flaw.

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 0% parameter coverage, the description should carry more of the explanatory burden. It omits parameter semantics, return behavior, and result limits, leaving significant gaps for a three-parameter search tool.

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% — parameters have titles only. The description provides no additional meaning for project_id, name, or max_results, leaving the agent without guidance on expected values or formats.

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 ('Find') and resource ('symbols') and scopes it to a 'hosted source-free code map without accessing a customer checkout.' This distinguishes it from checkout-based alternatives, though it does not explicitly name sibling tools like find_symbol or lsp_symbols.

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 phrase 'without accessing a customer checkout' — use this when you lack or want to avoid checkout access. However, no explicit when-to-use, when-not-to-use, or alternative tool routing is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the fingerprint comparison is optional and is used to detect staleness, which is useful behavioral context, but it says nothing about output shape, cost, or auth needs.

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 names the primary action first and the optional secondary action second, with no filler or redundancy.

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 status tool with no output schema and two undocumented-in-schema params, the description conveys the general intent but omits the return structure (what 'counts' look like) and the meaning of project_id, leaving the agent to guess at invocation details.

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 carries the load for two params. It usefully clarifies that source_fingerprint is an optional local fingerprint used for staleness comparison, but project_id is left entirely unexplained and no format or example values are given.

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 ('Report') and resource ('map counts'), plus the staleness-comparison function, which distinguishes it from the map-family siblings like map_find_symbol and map_dependency_graph. However, the terms 'hosted source-free map' and 'local source fingerprint' are internal jargon that an agent cannot fully resolve from the text alone.

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 explains what the tool does but gives no guidance on when to use it versus alternatives, no prerequisites, and no mention of the ingest_code_map / export_code_map siblings it logically relates to. The agent must infer the context entirely.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds two genuinely useful behavioral facts: the evidence is deterministic (repeatable) and the tool is advisory only, not a gate. It says nothing about permissions, runtime cost, or what evidence is actually collected, so it stops at adequate.

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 zero filler, and the most decision-relevant constraint (no release decision) is placed where it will be read immediately.

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, the description carries the burden of explaining what the agent gets back, and it does not — 'evidence' is left abstract with no indication of report shape or categories covered. For a single-parameter read-only tool this is minimally sufficient but leaves a real gap for an agent deciding whether to call it.

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?

There is one parameter (repo_path) with 0% schema description coverage, and the description does not mention it at all. No format is given (absolute vs relative path, remote vs local, whether it must be a git root), so the description fails to compensate for the schema gap even though the parameter name is largely self-explanatory.

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 ('gather'), a specific artifact ('deterministic evidence'), and the domain ('production readiness'). It is clearly distinguishable from siblings like run_tests or security_scan, but it never names an alternative or delimits what 'evidence' covers, so differentiation is implied 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?

Usage is only implied: an agent can infer it should call this when assessing whether a repo is production ready. The clause 'makes no release decision' is a useful scope boundary, but no alternatives are named and there is no when-not guidance relative to security_scan, run_tests, or diagnostics.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return context (subjects and refs) and scope (repo or one file), but does not disclose pagination, output format details, or authentication requirements.

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 no filler or redundant wording. It is appropriately concise, though its terseness contributes to gaps in parameter and usage guidance.

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 0% schema description coverage, the description should carry more of the burden for correct invocation. It gives only a high-level summary and omits parameter formats, defaults, and usage distinctions from other Git-related sibling 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 0% for 3 parameters, so the description must compensate but largely does not. It conceptually maps to repo_path, file_path, and a time window, yet provides no syntax, accepted formats, default behavior, or naming for parameters like 'since' or 'file_path'.

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 resource (commits) and scope (repo or one file, within a time window) and states what is returned (subjects and refs). It is clear enough to distinguish from generic repo tools, but it does not explicitly differentiate itself from siblings like git_diff or analyze_change.

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 guidance, no when-not-to-use guidance, and no mention of alternatives such as git_diff or repo_overview. The time-window phrasing implies a use case, but the agent is left to infer selection criteria.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context with 'fast' and 'evidence-only,' signaling low latency and that results are raw findings rather than inference or recommendations — but it says nothing about output format, cost, or whether it scans the working tree versus the index.

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 tightly written sentence with the core action front-loaded and no filler. It is dense with enumerated scope, which is efficient, though the list-of-nouns style slightly blurs what each item actually reports.

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, the description must convey what comes back, and it does so only via an enumeration of inventory categories. Combined with the missing path-format guidance and lack of sibling differentiation, the definition is adequate but leaves an agent guessing about return structure and where this fits in a workflow.

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?

There is one required parameter, repo_path, with 0% schema description coverage, so the description carries the full burden — and it says nothing about expected format (absolute vs relative path, root vs subdirectory) or behavior for an invalid path. A single-sentence mention of path semantics would have closed this gap.

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 ('Gather') and resource ('repository shape') and enumerates the inventory dimensions (languages, tests, index freshness, deployment artifacts). This clearly differentiates it from single-dimension siblings like language_profile or software_inventory, though it never names an alternative directly.

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 gives no when-to-use guidance and never contrasts itself with the many overlapping siblings (language_profile, software_inventory, production_readiness, diagnostics). An agent must infer that this is the broad first-pass reconnaissance tool rather than a focused analyzer.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context that execution happens in an isolated sandbox or disposable copy and that output is 'bounded evidence', but never explains what bounded means, timeouts, or failure behavior. This extra context earns above baseline without being 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?

A single dense sentence that front-loads the verb and outcome, with no wasted clauses. Slightly overloaded with environment detail but efficient overall.

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?

No output schema and 0% parameter coverage mean the description must carry more weight, but it omits parameter meanings, result format, and failure/timeout behavior. Assertions like 'bounded evidence' are unexplained, leaving real gaps for an execution tool.

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% across four parameters (scope, runner, timeout, repo_path), so the schema explains nothing. The description compensates only weakly: 'detected ... test suites' hints at runner auto-detection but scope, timeout, and repo_path semantics are entirely absent.

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 (runs) and resource (detected project-native test suites) with execution environment detail (sandbox worker or disposable local copy). It is distinguishable from nearby tools like test_plan, though it never names the sibling explicitly, so it falls 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?

The description gives no guidance on when to use this tool versus test_plan or other analysis tools, and no prerequisites or exclusions. The agent must infer usage from the name alone.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds value by disclosing that the search is bounded (results capped) and that results are file-and-line evidence, which is useful behavioral context beyond the annotations.

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. Every clause (bounded, supported source and configuration files, file-and-line evidence) carries information.

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, so the description must be self-sufficient, and it does convey the return shape. However, with three undocumented parameters and no explanation of supported file types or query semantics, it is only minimally complete for a search tool with this sibling set.

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 schema provides no parameter documentation at all. The description mentions query/repo_path only at the conceptual level and says nothing about max_results, query syntax, or what 'supported' files means, so it fails to compensate for the coverage gap.

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 (search) and resource (text across supported source and configuration files) and the output shape (file-and-line evidence). It implicitly distinguishes itself from symbol-oriented siblings like find_symbol by specifying 'text search', though it never names an alternative explicitly.

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 versus find_symbol, search_logs, or repo_overview, and no prerequisites or exclusions are stated. The word 'bounded' hints at limits but does not tell the agent when this tool is the right choice.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered by structured data. The description adds that it operates over a log file and matches lines, but says nothing about query syntax, case sensitivity, regex support, or pagination – useful context is thin but the annotation bar is lower.

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 efficient sentence with no waste, front-loaded with the verb and object. Short in the sense of under-specification rather than elegant conciseness, but structurally fine.

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?

No output schema exists, so the description should explain the return shape, but it doesn't. Combined with 0% parameter coverage and no sibling differentiation among a crowded toolset, the definition is incomplete for an agent to call it correctly.

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 adds no meaning for any of the three parameters. Query and log_path are not defined (syntax, format, relative vs absolute path), and max_results is left entirely to the schema default. With zero coverage, the description needed to compensate and does not 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 verb and resource (searches a log file for matching lines), which is clear enough. However, it gives no sibling differentiation despite many near-neighbors like search_code, git_diff, and recent_changes – an agent cannot tell from the description how this differs from those log/code search tools.

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, when-not-to-use, or alternative-tool guidance is present. The description offers no context for selecting this over search_code or recent_changes.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds two useful facts beyond that: the scanner is operator-configured rather than parameter-driven, and results come back as 'evidence'. It does not disclose scope, runtime cost, or failure behavior.

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 efficient sentence with the verb and the configured-scanner qualifier front-loaded. Nothing is padded, though one more clause on scope/usage would have earned 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?

No output schema, an entirely undocumented required parameter, and no disambiguation from two sibling scan tools. For a tool that executes a scanner and returns findings, the description leaves too many invocation questions unanswered.

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?

One required parameter (server_path) with 0% schema description coverage, and the description says nothing about it — no format, no example, no statement of whose server it is. With the schema carrying zero explanatory text, the description should have compensated and does not.

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 (run) and resource (the operator-configured MCP security scanner) plus the outcome (findings as evidence). 'MCP security scanner' loosely separates it from siblings like code_security_scan and vulnerability_scan, but the description never explicitly says what class of target it scans, so an agent still has to guess between the three scan tools.

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 at all, no prerequisites, and no mention of the obvious alternatives (code_security_scan, vulnerability_scan, diagnostics). The phrase 'operator-configured' hints that configuration must pre-exist, but that is not framed as a usage condition.

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?

Annotations already cover read-only, idempotent, and non-destructive safety traits. The description adds genuinely new behavioral context: it operates offline ('without network access'), is scoped to local manifests/lockfiles, and extraction is 'bounded'. It stops short of describing return shape, but the annotations carry the safety burden.

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 well-formed sentence that front-loads the verb and resource, then layers scope and the offline constraint. No filler or redundancy.

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, read-only tool whose annotations already declare the safety profile and with no output schema, the description conveys the essential scope (offline, local manifests/lockfiles, cross-language coordinates/PURLs). Minor gaps remain around output format and supported ecosystem coverage.

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 would need to compensate for the lone repo_path parameter, and it does not mention it at all. The parameter name is self-explanatory for a repo-scanning tool, so a baseline 3 is fair rather than penalizing further.

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 (Extract) and resource (cross-language dependency coordinates and Package URLs) with scope (local manifests and lockfiles). It is clear what the tool produces, though it never explicitly differentiates itself from closely related siblings such as dependency_graph or cyclonedx_sbom.

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 or named alternative. The phrase 'without network access' implies an offline context but doesn't say when an agent should choose this over dependency_graph, cyclonedx_sbom, or dependency_health.

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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds the meaningful guarantee that project code is never executed during detection, which resolves a plausible confusion with run_tests that annotations alone do not address.

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 what is detected, what is reported, and the key behavioral boundary, with 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?

With no output schema, the description carries the burden of describing the result, and it does say it reports per-toolchain local availability. It omits any detail on report structure or failure modes, a minor gap for a simple read-only tool.

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?

There is one parameter (repo_path) with 0% schema description coverage, and the description says nothing about it. The name is largely self-explanatory, but the description does not compensate for the coverage gap with path format or scope details.

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 specific verbs (detect, report) and resources ('allow-listed test runners', 'required toolchain'), so an agent knows this is a capability-detection tool rather than an execution tool. It stops short of naming the sibling it contrasts with (run_tests), so it is clear but not fully differentiated.

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 clause 'without executing project code' strongly implies the counterpart tool (run_tests) and implies when to prefer this one, but it never explicitly says 'use this instead of run_tests to check availability first' or states any precondition.

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?

Annotations already declare it safe, idempotent, and non-destructive, and the description adds real behavioral context beyond that: it depends on an operator-installed binary, queries osv.dev over the network by default, and can be switched to a pre-downloaded DB via ENGINEERINGOS_OSV_SCANNER_OFFLINE=1. It still omits the failure mode when the scanner is missing.

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, zero filler, with the core action front-loaded and the environment-variable caveat following. Every clause 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?

For a tool wrapping an external binary with a network dependency, the description covers invocation context but says nothing about what a result contains (findings, severity, clean vs. failed scan) and there is no output schema to compensate. Adequate but with clear gaps given the tool's complexity.

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 carries the full burden, yet it never mentions repo_path or timeout. An agent learns nothing about what repo_path should point at (root vs manifest dir) or how timeout is interpreted, beyond the schema's bare default of 120.

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?

Specific verb+resource: runs OSV-Scanner against detected dependency manifests to find known-vulnerability matches. This is clearly distinct from code_security_scan or dependency_health, though it never names a sibling to contrast against.

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 the scenario (auditing dependency manifests for CVEs) and gives a useful operational note about the default network call, but it never states when to choose this over security_scan, code_security_scan, or dependency_health, nor when not to use it.

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