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

Annotations only declare readOnlyHint/openWorldHint. The description adds substantial behavioral context beyond them: deterministic rules with no LLM in the decision path, the vendor_stack cap on the verdict, the $0.12 USDC x402 price, and the exact unpaid-call failure/retry protocol. This is exactly the kind of context annotations cannot carry.

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 dense sentences, front-loaded with the verdict purpose then the constraint then the billing. Every sentence earns its place, though the payment-retry sentence is somewhat long and could be trimmed.

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 names the three possible verdicts and explains the failure/payment path, so an agent can invoke and interpret it. It stops short of describing the full response body for a successful call, but coverage is adequate for a read-only scoring 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%, so parameters are already well documented. The description's vendor_stack and asset_context notes largely restate what the schema already declares. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific output (deterministic auto_approve/human_review/reject verdict) for a specific resource (planned remediation action against actor/sector/region context). It even lists the concrete action types it gates (block_ip, quarantine_host, halt_pipeline) and names its sibling lineage (/ot/threat-score) without requiring the schema to be opened.

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?

Clear context for use — gating a planned remediation action before execution — and it states the vendor_stack condition that caps the verdict at human_review. It distances itself from getThreatScore by noting the added auditable rules, but never gives an explicit 'use this rather than X when Y' routing statement.

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