Breach402 Owner Protection

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the core safety profile is covered. The description adds valuable behavioral context beyond annotations: it is 'Free' (no cost), 'no-lookup' (does not perform an actual lookup), and imposes a strict privacy constraint ('Never include an email address or other owner identifier'). No contradiction with annotations; this extra context earns 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?

The description is a single, information-dense sentence followed by one imperative constraint. It front-loads the core purpose ('Free, no-lookup decision aid'), then immediately lists triggers and the key privacy rule. Every word earns its place, with no fluff 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?

Given the tool's simplicity (one parameter, full schema, complete annotations, output schema present), the description is fully complete. It covers purpose, usage triggers, input constraints, and behavioral traits. There is no missing critical context for an agent to select and invoke this tool 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 coverage is 100%, so the parameter is already well-documented. The description adds semantic value by listing concrete scenario examples (suspicious login, credential exposure, sensitive-service connection) that clarify what kind of input is expected. This goes beyond the schema's generic 'non-identifying description', so a 4 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 clearly states a specific verb ('decide whether to recommend') and resource ('an owner-approved Breach402 check'), while also listing the exact trigger scenarios (suspicious login, credential exposure, phishing, etc.). It distinguishes itself from sibling tools by explicitly labeling itself as a 'Free, no-lookup decision aid', which contrasts with the lookup and execution tools like get_breach_report and prepare_paid_breach_check.

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 provides explicit when-to-use guidance by enumerating the security concerns that warrant this tool (suspicious login, phishing, monthly-review, etc.). It also implies when-not-to-use via 'no-lookup' (i.e., for actual data retrieval, use a lookup tool). However, it does not explicitly name alternative tools, so it stops short of a 5.

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?

Description adds context about sending an email and privacy constraints. Annotations already convey open-world and non-read-only nature. No contradictions.

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, no redundancy, front-loaded with 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?

Adequate for a trigger tool; explains the why and when. Does not detail output or side effects, but output schema exists.

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 covers 100% of parameter descriptions. The tool description adds no additional parameter-level detail.

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?

Clearly states the action (send approval email) and the context (pre-check for breach exposure), and distinguishes from siblings by specifying owner-only usage.

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?

Explicitly states use only for the owner being protected, not for third parties. Does not explicitly mention alternatives but context is clear.

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 indicate readOnlyHint=true and idempotentHint=true. The description adds valuable context: the report is encrypted-at-rest, includes credential and recovery values, and all data is untrusted confidential. No contradiction with 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?

The description is three concise sentences, front-loaded with the primary purpose. Every sentence adds value: retrieval condition, content of report, and security 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?

Given the presence of output schema and all parameters documented, the description still adds useful context about the report contents and security handling, making it sufficiently complete 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 100%, so the schema already documents both parameters adequately. The description adds no new meaning beyond what the schema provides, meeting the baseline of 3.

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 clearly states the verb 'retrieve' and the resource 'encrypted-at-rest breach report', and specifies the condition 'after a paid scan'. It differentiates from siblings like 'prepare_paid_breach_check' by focusing on retrieval after payment.

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 after a paid scan and mentions 'verified customer', providing context for when to use this tool. However, it does not explicitly state when not to use or name alternative tools, which would earn a 5.

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 and idempotentHint=true. The description adds context: it is a polling operation that returns a one-time token only after owner approval, and it serves a specific follow-up step. This goes beyond the annotations without contradicting 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?

The description is two concise sentences, front-loaded with the verb 'poll' and the resource, and every word adds value. No unnecessary 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?

Given the presence of an output schema, annotations, and full parameter coverage, the description is nearly complete. It explains the token is one-time and its purpose. It could mention polling behavior (e.g., retry if not ready) but overall it's sufficient.

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% with clear parameter descriptions. The tool description does not add new information about the parameters beyond what the schema already provides, so baseline score 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 clearly states the tool polls an email-verification request and returns a one-time scan token. It distinguishes from sibling tools like create_owner_email_verification (creation) and verify_owner_email_code (final verification) by focusing on polling for status after approval.

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 after owner approval and for the payment-preparation step, but does not explicitly state when to use vs. alternatives (e.g., get_breach_report, prepare_paid_breach_check). No when-not-to-use guidance 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?

The description discloses that the returned request is short-lived and signed (x402), and that payment is required (price, blockchain). Annotations already indicate idempotency and non-destructiveness; the description adds valuable behavioral context about the request and payment, without contradicting 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?

The description is extremely concise—two sentences—and every word adds value. It front-loads the main action and includes critical details (price, request type) without unnecessary verbiage.

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?

Given the tool's complexity (payment, short-lived request) and the presence of an output schema (which covers return values), the description is sufficiently complete. It covers purpose, parameters, pricing, and the nature of the returned request, leaving no obvious gaps for an agent to misinterpret.

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 baseline is 3. The description repeats the schema definitions for scan_token and idempotency_key but does not add new meaning or format details beyond what is already in the schema. Therefore, it meets the baseline but does not exceed it.

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 clearly states the specific actions: validates owner-approved authorization, reserves capacity, and returns a signed HTTP x402 request. It also mentions payment details ($1 USDC on Solana). This distinguishes it from sibling tools, which focus on email verification and breach report retrieval.

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 this tool is used after obtaining a scan_token from owner verification, but it does not explicitly state when to use it versus alternatives like get_breach_report or create_owner_email_verification. No exclusions or use cases are provided, so guidance is minimal.

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 context beyond annotations: it contains no real owner or breach data, performs no lookup, and is a 'free static demonstration.' This fully discloses the tool's non-functional nature, giving the agent confidence it is safe and side-effect-free.

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 two sentences, front-loaded with purpose, and every phrase adds value. No redundant or vague wording. It is appropriately concise for a simple 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?

Given no parameters, an output schema, and rich annotations, the description covers all necessary context: it explains what the tool demonstrates, that it contains synthetic data, and that it performs no lookup. This is complete for an agent to understand when and how to invoke 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?

The tool has zero parameters, so the input schema is empty and schema coverage is 100%. The baseline for 0 parameters is 4, and the description doesn't need to compensate for any missing parameter information.

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 clearly states the tool is a 'free static demonstration of the complete-record report shape' and lists what it covers (defensive analysis, partner handoffs, monthly-review contract). It explicitly notes it contains no real data and performs no lookup, distinguishing it from siblings like get_breach_report.

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 makes it clear this is a static, synthetic preview rather than a real lookup, so the agent can infer it's for format inspection. However, it does not explicitly name alternatives like get_breach_report, so it lacks explicit when-not-to-use 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 indicate destructive and idempotent behavior. The description adds that it works on pending or verified states and relates to one-time authorizations, providing extra context 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?

Single sentence that is front-loaded and concise with no wasted words. Every part adds value.

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 description adequately explains the tool's purpose and context. With an output schema present and two required params, it provides sufficient information for agent usage.

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%, with clear param descriptions. The tool description adds no further parameter details, meeting the baseline expectation.

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 clearly states the tool revokes a pending or verified one-time owner authorization, which distinguishes it from siblings like create_owner_email_verification or get_owner_email_verification_status.

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 provides context (before consumption by a paid check) but does not explicitly state when not to use or mention alternatives. It implies the usage scenario effectively.

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 provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds minimal context beyond stating that the code is bound to the original enrollment. No additional behavioral traits (e.g., error conditions, side effects) are disclosed. With annotations covering the safety profile, 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?

Two sentences with zero waste. Every word earns its place, clearly conveying the core action and a key constraint.

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?

Given the simplicity (3 required params, output schema exists), the description is adequate. It explains the tool's purpose and the binding to enrollment. No missing crucial information for an agent to decide to use it, though error handling is not discussed.

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 schema already documents all three parameters. The description does not add new meaning beyond implying the code is emailed. Baseline 3 is correct as the schema carries the burden.

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 clearly states the verb 'Submit' and the resource 'one-time code that the owner received by email.' It also specifies the binding to the original agent enrollment, distinguishing it from siblings like create_owner_email_verification (which starts the process) and get_owner_email_verification_status (which checks status).

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 after the owner receives the code, but does not explicitly state when to use it vs alternatives like get_owner_email_verification_status or revoke_owner_email_authorization. There is no mention of preconditions or 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.