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 the three detection categories (hallucinated packages, typosquatting, boundary breaches), which is real behavioral content, but it omits whether the audit is read-only, what permissions it needs, or whether it produces side effects.

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. It efficiently packs verb, resource, and detection scope into one line.

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 should explain what an audit returns (findings, severity, report format), but it does not. Combined with the absence of annotations, an agent gets no sense of the shape or nature of the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is fully described in the schema as a 'Unified git diff string to audit.' The description adds no syntax or format detail beyond that, and its mention of 'Pull Request' is not reflected in the required diff parameter.

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 (Audit), a specific resource (git diff or Pull Request), and enumerates exactly what it looks for: AI-hallucinated packages, typosquatting, and architecture boundary breaches. No sibling tool overlaps, so an agent can identify it instantly.

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, when-not-to-use, or prerequisite information. The description says what the tool does but never tells the agent under what circumstances it should be preferred or avoided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the detection categories and a latency claim, but omits authentication requirements, rate limits, and what the response actually looks like, leaving meaningful behavioral gaps for a lookup service.

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 that states the input, performance claim, and detection scope without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter lookup tool with no annotations and no output schema, the description covers the input and detection categories but does not describe the return format or result semantics. The agent knows what to pass but not exactly what structure to expect 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 100%, and the single parameter is fully documented in the schema with the same IPv4 example format provided in the description. The description adds no syntax or semantic detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Query') and resource ('IPv4 address') and explains what the query detects: Datacenter/Cloud servers, VPNs, Tor, and bot proxies. The function is immediately clear, and the sibling tools are unrelated, so no further differentiation is needed.

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 detection categories imply the tool's use case (IP intelligence / proxy detection), but there is no explicit guidance on when to use it versus alternatives or any exclusions. This is adequate implied usage, not explicit routing advice.

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. It usefully discloses that analysis is static rather than a build execution, implying a safe read-only operation, but it says nothing about the return shape, severity model, or whether findings are ranked.

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

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

A single dense sentence with the verb-resource pair front-loaded and the checked categories listed after. No filler, nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter audit tool with no output schema and no annotations, the description covers the input and inspection criteria well, but leaves the structure of the audit results (findings, severities, format) entirely unspecified.

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 with 100% schema description coverage, so the schema already documents 'dockerfileContent'. The description adds no syntax or format guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb (audit), resource (Dockerfile), and scope (statically), then enumerates exactly what it checks: layer bloat, cache invalidation, root user, missing multi-stage build. No sibling tool overlaps this domain, so an agent can route to it unambiguously.

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 word 'statically' implies this is for inspecting a Dockerfile without building it, which is useful context, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage must be inferred from the description.

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. It discloses that the tool detects specific purchase patterns and produces a quantitative conviction score, and the word 'Parse' strongly implies a read-only operation. However, it does not describe response shape, error handling, permissions, or rate limits, so meaningful gaps remain.

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 that states the operation, the input types, and the analytical outcome. There is no filler or repetition, and every clause contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one required parameter, no nested objects), but there is no output schema and no annotations. The description hints at an output ('quantitative conviction score') but does not explain what the response contains, how the score is structured, or what happens on invalid input. It is minimally viable but leaves the agent guessing about return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single parameter is already documented in the input schema. The description adds useful semantic constraint by specifying that the XML must be an SEC Form 4 or 8-K filing, narrowing the valid input beyond the schema's generic 'Raw SEC XML filing content'.

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 precise verb ('Parse') and names the exact resources (SEC Form 4 or 8-K XML filing), then specifies the analytical target (C-suite open market cluster purchases with quantitative conviction score). An agent can immediately tell what the tool does and what it produces. The sibling tools are unrelated, so no further differentiation is needed.

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 explicit when-to-use or when-not-to-use guidance, and it names no alternatives. An agent must infer that this tool should be used whenever a Form 4 or 8-K XML filing needs parsing for cluster purchases. There are no prerequisites, exclusions, or routing instructions.

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 mentions the analytical method (Markov chain transition matrices) but omits whether the operation is read-only, what the output contains, computational cost, or any side effects.

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 is appropriately sized for a one-parameter tool. There is 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?

No output schema exists, so the description should explain what the analysis returns (e.g., stability metrics, flaky test lists). It also does not clarify the 'quarantine' aspect implied by the tool name, leaving the definition incomplete for an analysis 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 100%, and the single parameter is fully described in the schema. The description adds no new parameter details, so the baseline of 3 applies.

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

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

The description states a specific verb ('Analyze'), resource ('test stability'), input source ('multiple JUnit XML runs'), and method ('Markov chain transition matrices'). It is clear enough to distinguish from the unrelated sibling tools, though it does not specify what aspect of stability is reported.

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, prerequisites, or alternatives are provided. The description offers no context about when this analysis is appropriate or what to do with its results.

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 it only discloses one trait (6-axis orthogonal rotation). It omits determinism/reproducibility, whether packing is a pure read or has side effects, performance characteristics, and what happens when items cannot be packed.

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

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

Two tight sentences with the core operation front-loaded and no filler. It is efficient, though it is arguably too terse given everything the tool leaves 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?

No output schema, no annotations, and no parameter documentation mean the description should carry much more. It never explains the return value (carton assignments? placement coordinates? unplaced items?), which is the single most important thing an agent needs from a packing optimizer.

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 single 'items' parameter is a nested array with five undocumented sub-fields. The description adds no units (w/h/d in cm or inches? weightKg in kg?), no id semantics, and no mention of carton constraints despite referencing 'available cartons' that have no corresponding parameter.

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 — 'Packs multiple 3D items into available cartons' — plus the optimization qualifier and the 6-axis rotation behavior. It is unambiguously distinguishable from every sibling, none of which touch geometric packing.

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 is given. The description never says where the 'available cartons' come from, whether rotation can be restricted, or what conditions make this tool the right choice. It only describes the operation, not the decision to invoke it.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses a key guarantee — that foreign key joins and unique constraints are preserved 100% — which is real value beyond structured fields. However, it omits whether output is returned inline versus streamed, whether results are deterministic, and any performance or size limits, leaving significant gaps for a mutation-style 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?

A single sentence with the core action front-loaded and no filler. Every word earns its place, and the most important guarantee is 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?

For a simple two-parameter tool with full schema coverage, the description covers purpose and the referential-integrity guarantee adequately. With no output schema and no annotations, though, it should still state what is returned (anonymized SQL text) and whether the operation is deterministic, so it is only minimally 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 100%, so both parameters are already documented in the schema, and the description adds no syntax or format detail beyond them. Baseline 3 is appropriate; the mention of preserving joins hints at why determinism matters but doesn't clarify the secretSalt parameter's role.

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

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

The description pairs a specific verb (Anonymize) with a specific resource (raw SQL dump content), so an agent immediately knows what the tool does. Sibling tools are entirely unrelated domains (audits, trimming, lookups), so no sibling differentiation is required, but the description stops short of a 5 because it doesn't scope which kinds of dumps or transformations apply.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative guidance. The phrase 'raw SQL dump content' implies the input context, but an agent gets no help on prerequisites (e.g., whether a secretSalt is required for deterministic output) or on how this differs from any other processing step.

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 disclosure burden. It usefully names the three analytical outputs, but says nothing about safety profile (read-only vs. mutating), whether the plan is sent to a remote service, cost estimation accuracy, or size/rate limits on the input.

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 with no filler, front-loading the verb and the three value dimensions. Every phrase 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 one-input analysis tool with no output schema, the description names the three report dimensions so an agent knows roughly what comes back. Minor gap: no indication of output format or how the input plan JSON must be produced.

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 parameter with 100% schema description coverage, so the schema already documents 'planJson' as Terraform plan JSON content. The description adds nothing beyond that baseline, which is the expected 3 when the schema does the heavy lifting.

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

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

States a specific verb ('Evaluate') plus resource ('Terraform JSON plan') and enumerates the three analyses produced: blast radius, stateful resource destruction, and monthly FinOps cost delta. Sibling tools are all in unrelated domains, so no differentiation is needed and none is missing.

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 never states when to reach for this tool versus alternatives, nor any prerequisites (e.g., plan must be generated with 'terraform show -json'). Usage is only implied by the input name.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: the transformation collapses method bodies and yields a quantified 50%-70% token reduction. It stops short of warning that the output is a lossy, non-executable representation, that signatures/imports are preserved, or any limitations, which matters for a source-rewriting tool.

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

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

A single tight sentence that front-loads the action and resource and then quantifies the payoff. No filler, no 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 simple two-parameter tool this is close to sufficient, but with no output schema the description never states that the return value is the pruned source (or its format), and it omits any caveat about the transform being lossy. Those gaps keep it at a minimum-viable level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (sourceCode, filename) are already documented in the schema, establishing the baseline of 3. The description adds no syntax, format, or size guidance for either parameter beyond what the schema provides.

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 (prune), a precise resource (TypeScript/JavaScript source code), and the mechanism (collapsing method bodies). The resource is narrow enough that it is trivially distinguishable from all unrelated siblings such as cidr_shield_lookup or edgarpulse_parse_filing.

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 use case is strongly implied by the stated goal (reducing LLM context token usage), so an agent can infer when to reach for it. However, there is no explicit when/when-not guidance, no statement that it only applies to TS/JS, and no caution about alternatives or fidelity trade-offs.

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