security-preflight

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only a restatement of the title's content categories, with no new behavioral context such as where the scope/evidence data comes from or how fresh it is.

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 short sentence with no filler and the key concept front-loaded. It is efficient, though the four-noun enumeration reads as boilerplate rather than a precise statement of purpose.

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 an output schema present, return values need not be explained, and the read-only annotations cover safety. What remains missing is the crucial disambiguation of which agent's scope and evidence boundary this returns, which an agent needs in order to pick this tool over its 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?

The tool takes zero parameters, so per the baseline the schema carries no semantic burden. The description's mention of 'inputs' is generic and adds nothing, but no penalty applies for an empty 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?

The description gives a verb ('Describe') and an object list ('scope, evidence boundary, inputs, and outputs'), so it is not a pure tautology, but it never says which agent or whose scope is being described, and it offers no differentiation from siblings like get_security_receipt or security_preflight. The purpose is inferable but vague.

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 call this tool, no prerequisites, and no mention of the alternative sibling tools that also relate to security assessment. The agent gets no routing guidance at all.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is low. The description nevertheless adds meaningful data-integrity context: the returned receipt is 'unsigned' and 'filtered' (i.e., redacted/public), which tells the agent the content is non-authoritative. It stops short of saying what gets filtered out or what auth is needed.

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 compact sentence with the core read semantics front-loaded and the caveat second. It wastes no words, though its extreme terseness is part of why the purpose and parameter details are missing.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. But for a tool with a 0%-documented required id parameter and no named alternatives among the security-related siblings, the description is only marginally sufficient for correct invocation.

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

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

There is one required parameter, receipt_id, and schema description coverage is 0% — the schema documents nothing about it. The description does not mention the parameter at all, so it fails to compensate for the coverage gap; an agent gets no hint about the id's format, source, or whether it matches the original delivery's 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 verb 'Read' is clear, but the description never names the resource it operates on (a security receipt) — that identity comes only from the tool name and title. It does distinguish the object from the 'original delivery', which hints at scope, but an agent reading the description alone would not know what entity it is fetching.

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 'retain original delivery for signature verification' implies this filtered view is not suitable for signature verification, which is useful when-not guidance. However, no sibling tool is named, no conditions for choosing this over the original delivery are spelled out, and the guidance is buried in a semicolon clause rather than stated as an instruction.

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 are weak (all mutation hints false), and the description adds real behavioral context beyond them: hard limits (64 KiB, 2000 lines, 4096 chars/line), explicit exclusions (no model calls, no repository fetching, no code execution), and the return artifact (redacted signed receipt). It stops short of explaining why readOnlyHint is false, i.e., what state the session requirement mutates.

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 core purpose and limits. The middle sentence about 'checkout caller' and 'fixed-order session' is cryptic but earns its place as a prerequisite note; 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 an output schema present, the return contract need not be spelled out, and the description adequately conveys the operation's bounds and side-effect exclusions. However, for a tool with 0% parameter coverage, the complete absence of parameter guidance leaves a real gap for correct invocation.

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

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

Schema description coverage is 0% and none of the three parameters (source, agent_id, session_id) are described. The vague mention of 'checkout caller' and 'verified fixed-order session' gestures at the session/auth inputs but does not tell the agent what agent_id or session_id should contain, so the description 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 (scan) and resource (inline VulnCanon source) with a clear scope qualifier ('$1 bounded', 'indicators, not proven exploits'). The term 'VulnCanon' is unexplained jargon, but the verb+resource pairing is unambiguous and distinguishes it from the other security-oriented 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?

'Direct MCP requires the checkout caller and verified fixed-order session' implies a prerequisite context, but it never states when to choose scan_source over screen_injection, security_preflight, or get_security_receipt. Usage is implied rather than routed.

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?

Beyond the annotations, the description discloses genuinely useful behavioral context: the output is 'heuristic indicators, not calibrated probabilities or a guarantee of safety,' that there are no model calls, and no automatic follow-on purchase. This clarifies the side-effect profile that the annotations (readOnlyHint=false, idempotentHint=false) only gesture at. It does not contradict them.

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?

Compact and front-loaded — the core operation leads, followed by constraints and caveats, with no filler sentences. The phrasing is slightly clipped ('$1 batch', stacked fragments), which costs a point but not clarity.

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?

An output schema exists, so return-format detail is unnecessary, and the description covers the key caveats and limits. Still missing enough for a 4–5: the role of agent_id, and any hint about what the indicator fields mean or how to interpret them.

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 compensate. It adds real semantics for 'texts' (batch of 1–20, 64 KiB total) and hints at 'session_id' via the 'verified fixed-order session' requirement, but says nothing about what 'agent_id' is or why it is required. Partial compensation only.

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 and resource: a batch of 1–20 text samples 'screened for deterministic injection markers.' That is more specific than the title alone and tells an agent exactly what comes back (heuristic indicators). It does not, however, differentiate itself from siblings like scan_source or security_preflight, 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?

Constraints are given (1–20 samples, 64 KiB total, 'Direct MCP requires the checkout caller and verified fixed-order session'), which implies when the tool is callable. But there is no explicit when-to-use guidance relative to scan_source or security_preflight, so routing among siblings is left 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 state readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description adds genuinely new context: a $1 cost, a signed receipt as the output artifact, prerequisites ('checkout caller and verified fixed-order session'), and the explicit statement that no endpoint is fetched or tested. That is meaningful disclosure beyond the structured fields.

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 purpose and return value are front-loaded, which is good, but the middle sentences about the MCP caller and the x402 rail's 'introductory quote policy' are jargon-heavy and their relevance to invoking the tool is unclear, costing the agent parse effort.

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 an output schema present, return-value explanation is not required, but for an 8-parameter tool with nested objects and 0% schema coverage, the description leaves too much unspecified. An agent cannot confidently populate manifest, policy, or the payment/session fields from this text alone.

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 8 parameters, including nested objects (manifest, policy, sample_inputs), and the description explains none of them. It only indirectly alludes to a session requirement, leaving agent_id, manifest, policy, and payment_ref semantics entirely undocumented.

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 concrete verb+resource ('Run a $1 static Security Preflight') and the return artifact ('signed receipt'), plus a scope qualifier ('No deployed endpoint is fetched or tested') that separates it from a live scan. It does not name any sibling tool, so the differentiation from scan_source/screen_injection is left 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?

It implies usage context by stating what does not happen (no endpoint fetched) and that importing the receipt is a separate action, which hints at a static-assessment use case. However, there is no explicit when-to-use/when-not vs alternatives, and the mention of MCP vs x402 rails reads as payment plumbing rather than selection guidance.

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