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 what the graph contains (subsystems, modules, drivers, symbols as nodes; dependency, hierarchy, usage as edges), but is silent on operational traits such as whether the build is idempotent, how expensive it is, what it requires as prior state, or where the result is stored.

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 action and sources, with no filler. The parenthetical '(Module A3, Rule R6)' is cryptic and references undefined labels, costing it a perfect score but not enough to be wasteful.

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 prerequisites and the shape of the result. It partially compensates by describing node and edge types, but omits whether the graph is persisted, how it is consumed, and what must exist beforehand for the build to succeed.

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 zero parameters and 100% coverage, so there is nothing for the description to clarify. The baseline for a no-parameter tool applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Build') and resource ('dependency graph') and names the data sources (kernel config, loaded modules, subsystem mappings), so the agent knows what it produces. It does not explicitly distinguish itself from the sibling query_dependency_graph, which reads a graph that this tool presumably constructs, leaving the build-vs-query split 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 prerequisites, and no mention of alternatives. The agent is not told whether scan_system must run first or whether this should be invoked before query_dependency_graph, which is the most natural sibling relationship in this toolset.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior: two evaluation gates (fix already present / not introduced, config mapping) and a guaranteed evidence chain on every verdict. It omits auth/permission needs, behavior when the CVE is unknown or the config mapping is absent, and any cost or latency characteristics.

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?

Three tight sentences with the core action front-loaded, followed by the evaluation gates and the output guarantee. The only friction is the unexplained shorthand '(R3)', which costs a little clarity for an agent with no key to the notation.

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 tool with no annotations and no output schema, the description covers the mechanism and one output property (evidence chain) but leaves the verdict shape, possible verdict values, and failure modes undefined. Adequate to call correctly, thin on what comes back.

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%, but the single parameter is a self-evident 'cveId' whose format is already pinned by the schema's regex pattern. The description says only 'a CVE', adding no syntax, sourcing, or format guidance beyond the schema, so it neither compensates nor misleads.

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 (cross-reference) and resource (a CVE) and scopes the operation to this system's version, config and modules, which separates it from a plain lookup like query_cve. It does not explicitly name a sibling tool to differentiate against, but the assessment semantics are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the two-gate framing (version range, config mapping) tells the agent this is the 'does this CVE affect me' step, presumably after query_cve and before find_patches, but no when-to-use, when-not, or named alternative is given. Nothing is misleading, but nothing routes the agent either.

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 mostly does: it discloses it writes only into a staging directory, explicitly never mutates the running system, and returns a conflict report plus evidence chain. Missing are prerequisites, overwrite behavior for an existing staging dir, and any permission requirements, keeping it from a 5.

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?

Three short, front-loaded sentences with no padding: purpose, behavior, return values in that order. The opaque rule identifiers (R4, R1/R5) cost a little clarity without adding length, but the structure is sound.

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 with no annotations and no output schema, the description usefully names the return artifacts, which compensates for the absent output schema. It still omits prerequisites (e.g., whether find_patches/scan_system must run first) and what happens with unresolved conflicts, leaving gaps for a write-capable 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 50%: outputDir and targetBranch are documented in the schema, while cveId and upstreamSha are bare. The description's "commit <sha> upstream" hints at what upstreamSha means and the staging wording reinforces outputDir, but cveId and targetBranch semantics are untouched, so it adds only marginal meaning.

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 (draft) plus resource (kernel-rule-compliant backport) and the destination (staging directory), with concrete outputs named (conflict report, evidence chain). It is unmistakably distinct from the query/dependency siblings, but never names or contrasts any 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?

"Never applies to running system (Rule R1/R5)" is a genuine exclusion, telling the agent this cannot be used to activate changes. However there is no positive when-to-use guidance and no routing relative to find_patches or scan_system, which an agent would need to know whether to run this first or after patch discovery.

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 well: it discloses live linux-cip mirror queries, backport commit and first tagged CIP release resolution, and graceful degradation to record-derived candidates (R1/R2/R4). It omits permissions and rate limits but is otherwise unusually transparent.

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 dense sentences are front-loaded with the action and provenance chain, then the mirror/fallback behavior. The R1/R2/R4 jargon may require external context, but there is little wasted text.

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 finder tool with no annotations or output schema, the description explains provenance and fallback behavior and hints at return fields (backport commit, first tagged CIP release). However, it leaves cveId format and the full return shape implicit, which are meaningful 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% for the single required cveId parameter, and the description only says 'for a CVE' without adding format, constraints, or examples beyond the schema pattern. It does not 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 (Locate) and resource (existing fixes/patch commits) for a CVE, and adds the provenance chain from mainline through stable to CIP branches. It does not explicitly differentiate from siblings like draft_backport, 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?

The description gives no when-to-use guidance, prerequisites, or alternatives. Its fallback statement describes behavior, not when to choose this tool over query_cve or cve_applicability.

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 discloses the source fallback behavior and the shape of the returned record (affected files, version ranges, fixing commits), which is real added context. It does not cover not-found behavior, rate limits, or auth needs, leaving a noticeable gap for a tool with zero annotation coverage.

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, front-loaded with the lookup action and following immediately with the return contract. The trailing '(R1/R3)' is an opaque internal reference that spends tokens without conveying meaning to the agent.

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 correctly fills the gap by enumerating the returned record's contents, and it explains the source resolution strategy. Missing error/not-found semantics and any indication of auth or limits keep it from being fully 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%, so the description should compensate. It only says 'by id', and while the schema pattern reveals the expected CVE-YYYY-NNNN format, the description adds no meaning about the identifier beyond that. This is minimum-viable rather than enriching.

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 (look up) plus resource (a CVE by id) with an explicit data-source strategy, so the agent knows exactly what it returns. It does not name or contrast with any sibling (e.g. find_patches, cve_applicability), so it falls short of the 5 bar for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states a resolution order (kernel.org first, NVD fallback), which is helpful, but that is behavioral rather than usage guidance. There is no statement of when to reach for this tool versus its siblings, nor any prerequisite or exclusion conditions.

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 behavioral burden and falls short: it never says the tool is read-only, whether the graph must first be created via build_dependency_graph, or anything about result size, depth limits, or latency. The only extra context is the cryptic provenance note 'Built from system inventory (Module A3, Rule R6)', which does not help an agent invoke it correctly.

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?

Three short sentences, front-loaded with the purpose and followed by the mode enumeration; nothing is padded. The trailing provenance sentence ('Module A3, Rule R6') is of dubious value to an agent and is the one part that does not clearly earn 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 5-parameter tool with no annotations and no output schema, the description should explain the read-only nature, whether the graph must be pre-built, and roughly what comes back. It covers query selection well but leaves these operational questions open, making it only adequate.

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 already 80%, establishing a baseline of 3, and the description adds real meaning by explaining what each queryType value computes and, implicitly, which node parameters pair with which mode. It does not clarify maxDepth behavior or the startId/endId pairing beyond what the schema already states, so it is above baseline but not complete.

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 ('Query a dependency graph') and enumerates the four query modes with parenthetical explanations, so an agent immediately knows what the tool does. It does not explicitly contrast itself with the sibling build_dependency_graph, so the build-vs-query distinction is only implied by the verb.

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 parentheticals ('what depends on these nodes?', 'what do these nodes depend on?', 'find paths between nodes') effectively tell the agent which query type maps to which question. However, there is no statement about when to use this tool at all versus scan_system or build_dependency_graph, and no prerequisites 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?

With no annotations, the description carries the full burden and does disclose that the operation is read-only and least-privilege (R2/R3), which tells the agent nothing destructive happens. However, it omits execution cost/duration, required permissions or elevation, host scope (local vs remote), and why R2/R3 matters — and 'read-only' is stated twice without added detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action before the safety qualifier. Slight redundancy in restating 'read-only' and unexplained jargon '(R2/R3)' cost it a point.

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 must carry the whole load. It does enumerate what the inventory returns, but leaves the response structure, scope of the scan, runtime, and privilege model (R2/R3 is never explained) unspecified — adequate but with clear gaps for a scan 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?

The tool takes zero parameters, so the baseline is 4; there is no argument syntax to clarify. The enumerated inventory contents describe output rather than inputs, so no further parameter credit is available or needed.

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 concrete verb+resource ('Collect a read-only kernel inventory') and enumerates the collected artifacts (version, config, loaded modules, distro), which is far more specific than the sibling tools like query_cve or find_patches. It does not explicitly name or contrast itself with any sibling, 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. 'Read-only, least privilege' describes a safety property, not usage context, so the agent must infer that this scan should precede cve_applicability or find_patches on its own.

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