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

No annotations are provided, so the description fully carries the burden. It discloses pricing, payment mechanism (x402), that Verity holds no key and never charges silently, and that affiliate_id never changes behavior. It also lists the return fields, offering comprehensive behavioral transparency.

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 longer than necessary but well-structured, front-loading purpose and usage, then adding pricing, return format, and OWASP mapping. Each sentence adds value, though some details (e.g., OWASP mapping) could be trimmed for a more concise read.

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 and no annotations, the description covers most essential aspects: purpose, usage timing, return fields, and pricing. However, it omits an explanation of the 'context' parameter, which is a gap. Overall, it is sufficiently complete for an agent to invoke correctly, but not perfect.

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 no descriptions (0% coverage). The description explicitly explains affiliate_id ('tags the call for a future referral program; it never changes price or behavior') but does not explain 'content' or 'context'. 'Content' is implied as the text to screen, but 'context' is left unspecified. This partial compensation warrants a mid-range score.

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's purpose with a specific verb and resource: 'Screen untrusted text or tool output for PROMPT-INJECTION / manipulation.' It distinguishes itself from sibling tools by naming the specific threat category and attack types (instruction-override, jailbreaks, multilingual attacks).

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?

Provides clear context: 'Use on anything an agent ingests from an outside source (web page, email, doc, tool result) BEFORE acting on it.' This implies when to use, though it does not explicitly name alternatives or exclusions. The guidance is sufficient for typical use.

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?

Despite having no annotations, the description discloses pricing, payment mechanism, abstention behavior, no-citation-fabrication guarantee, return values, and the affiliate_id's non-impact. This is rich behavioral context that goes far beyond the schema.

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 well-structured with clear sections, but the concluding OWASP/audit-artifact note is tangential. It could be trimmed without losing essential 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?

The description covers purpose, returns, pricing, alternatives, and safety behavior. However, it omits explanation of the context parameter and does not mention quick_verify for tier comparison, leaving a small gap in completeness.

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 description explains the claim parameter implicitly and gives a detailed note on affiliate_id, but it does not describe the context parameter at all. With zero schema coverage, this leaves the agent without guidance on what context means.

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 web-grounded reality-check on a claim, naming it the default product. It specifies the exact output and behavior, and distinguishes itself by instructing escalation to pro_verify, leaving no ambiguity about the tool's purpose.

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 explicitly says to use it right before an agent acts on, repeats, or surfaces a fact that matters, and advises escalating to pro_verify for deeper synthesis. However, it does not compare with quick_verify, leaving some ambiguity about when to choose the lighter sibling.

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 fully discloses behavioral traits: it is paid (~$0.02 per call, x402/USDC), fail-closed (uncertainty escalates to review, red flags block), returns a decision/risk/reasons/safer_alternative, and explicitly states pricing is disclosed and Verity holds no key. It also clarifies that affiliate_id never changes price or behavior. This goes well beyond basic operation and gives the agent a complete picture.

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 lengthy (~170 words) but well-structured with paragraphs: purpose, pricing, fail-closed behavior, return values, and affiliates. It front-loads the core purpose and adds essential behavioral details. Some phrasing is somewhat promotional ('THE MONEY-LINE GATE', 'honest 0-1 risk'), but it earns its length by covering key operational facts.

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 tool with no output schema, the description thoroughly explains the return structure (decision, risk, reasons, concerns, safer_alternative) and the fail-closed behavior. It also covers pricing and audit artifact. The main gap is parameter documentation for policy/context, but the tool's purpose and behavior are otherwise well-specified, making it usable for an agent in the intended high-stakes scenario.

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 0% description coverage, so the description must compensate. It explains affiliate_id (optional referral tag, no behavior change) and references 'action' implicitly, but provides no meaning for 'policy' or 'context' parameters. The agent is left to infer how to structure these fields, which is a significant gap for a 4-parameter tool.

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 decides whether a proposed agent action should proceed, specifically before irreversible actions like payments, messages, destructive commands, or data sharing. It distinguishes itself from siblings by framing itself as the 'money-line gate' for irreversible commitments, versus the verification/security tools in the sibling list.

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 explicitly says 'use this right before the agent SPENDS, SENDS, or commits something irreversible,' providing precise trigger conditions. It also contrasts itself with 'free local checks,' implying that for reversible or low-risk actions a local check may suffice, though it does not name specific sibling tools or provide explicit exclusions.

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 provided, the description carries full responsibility for behavioral disclosure. It goes well beyond the minimum by disclosing the exact price, payment mechanism (x402, USDC on Base), that all decisions are priced identically to prevent rent-seeking, that billing is transparent, and that affiliate_id never changes behavior. This is exceptional transparency.

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 front-loaded with purpose, then covers pricing, returns, and optional parameters. It is slightly redundant on pricing (mentioned three times: upfront, in pricing fairness, and in the disclosure sentence), but each sentence adds distinct value. It is well-structured and not bloated.

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 annotations and no output schema, the description is remarkably complete. It covers when to use, what it returns, how policy works, pricing details, and the affiliate_id behavior. There is no ambiguity about the tool's operation or cost. It fully compensates for the lack of structured metadata.

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%, so the description must compensate. It explains policy (optional, sets the standard, otherwise conservative default) and affiliate_id (tags for future referral program, never changes price/behavior). The content parameter is implicitly clear from the description's use of 'CONTENT' and the usage guidance. Adding allowed policy values would push this to a 5.

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 opens with a specific verb and resource: 'Decide whether CONTENT is safe to publish, post, or surface.' This clearly distinguishes the tool from sibling verification, detection, and redaction tools. It also includes the return categories (publish/review/block), reinforcing its unique role.

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 explicitly states when to use the tool: 'Use before an agent sends or publishes generated content.' It also explains the optional policy parameter and default behavior. However, it does not mention when not to use it or explicitly name alternatives among siblings, so it falls 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?

With no annotations, the description fully discloses behavior: pricing (~$0.35), payment via x402, no silent charges, abstains rather than guess, never fabricates citations, and returns a signed Ed25519 receipt. This is thorough and gives the agent confidence in invoking the 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?

The description is long but well-structured with clear sections (pricing, returns, behavior). Each sentence adds information, though the parenthetical on OWASP mapping is somewhat tangential and could be trimmed. Overall, it is appropriately dense without being bloated.

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 output schema, the description thoroughly explains return values (verdict, confidence, reasoning, evidence, receipt). It also covers pricing, payment, and abstention behavior, making it nearly self-sufficient for an agent. The only minor omission is the 'context' parameter, but this does not significantly hurt completeness.

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%, so the description must compensate. It explains affiliate_id ('never changes price or behavior') and claim is obvious from the tool's purpose, but the 'context' parameter is never described. This leaves a semantic gap for a parameter that could affect verification results.

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 performs a 'Premium, web-GROUNDED reality-check on a CLAIM — the deepest tier.' The verb 'reality-check' and resource 'CLAIM' are specific, and the 'deepest tier' phrase distinguishes it from sibling verification tools like quick_verify and grounded_verify.

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?

Explicit guidance is provided: 'reach for it when a claim is high-stakes and the grounded tier's answer isn't confident enough to act on.' It also mentions verify_receipt for free re-checks, offering an alternative path. This clearly indicates when to use the tool versus alternatives.

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 discloses key behaviors: abstains rather than guesses, never invents evidence, pricing is disclosed and paid per use, Verity holds no key, and affiliate_id does not change behavior. This is exceptionally transparent for a tool with zero annotation support.

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 concise and front-loaded with the core purpose. Each sentence adds value—covering price, usage, outputs, limitations, and affiliate details—without any 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?

Even without an output schema, the description explains the return values (verdict, confidence, reasoning, receipt) and includes pricing, limitations, and relationship to sibling tools. It is comprehensive for the tool's complexity.

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 thoroughly explains affiliate_id, and 'claim' is clear from the context, but the 'context' parameter is entirely unexplained. This leaves a meaningful gap in parameter semantics.

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 it is a 'Cheap, fast reality-check on a CLAIM' with a specific verb and resource. It explicitly contrasts with grounded_verify by calling itself 'ungrounded' and the 'inexpensive first pass,' distinguishing it from 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?

Provides explicit usage guidance: 'use it everywhere as the inexpensive first pass, then escalate the load-bearing ones to grounded_verify.' It also names the alternative tool (grounded_verify) and implies when not to use (for load-bearing claims).

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 fully takes on transparency: it discloses per-call pricing ($0.02 via x402), states Verity holds no key and never charges silently, describes what is flagged, lists return fields, and clarifies affiliate_id behavior. This is exceptional behavioral disclosure for a paid API.

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 bit longer then typical, but every sentence earns its place: purpose, pricing, use timing, return summary, pricing transparency, affiliate disclaimers, and OWASP mapping. It is front-loaded with the primary purpose and remains scannable despite its length.

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 there is no output schema, the description usefully enumerates return fields (verdict, severity, findings, reasons, redacted version). It also covers cost, security context, and affiliate behavior. The only notable gap is the undocumented context parameter, but the rest is thorough enough for a tool of moderate complexity.

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%, so the description must compensate. It explains payload well and explicitly describes affiliate_id's purpose and non-effect on pricing/behavior. However, the context parameter is not mentioned at all, leaving its meaning and intended use unclear.

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 ('Detect personal data and secrets') and clearly identifies the resource (PAYLOAD) and the broader purpose (before being sent, stored, or logged). It also distinguishes itself from sibling verification/guard tools by focusing on PII/secrets redaction and pre-transmission safety.

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 explicitly says 'Use before an agent transmits text outside a trust boundary,' giving a clear use-case. It doesn't name alternatives or state when-not-to-use, but the context is strong enough to guide selection among siblings.

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 provided, the description carries the full burden. It discloses key behavioral traits: stateless, free, no payment, affiliate_id inert, returns {valid: bool, reason: str}, validates Ed25519 signature, and supports offline validation via /.well-known/verity-pubkey.json. It could add more about error handling or rate limits, but is notably transparent for a verification 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?

The description is well-structured with line breaks, front-loaded with the key message 'FREE. Statelessly verify...'. It contains some redundancy (price is stated twice) and is somewhat long, but every sentence adds useful context and it remains readable.

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 output schema and no annotations, the description is remarkably complete. It covers purpose, usage, return format, authentication needs (none), payment (none), and even mentions the offline validation endpoint. It provides all necessary information for an agent to select and invoke the 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 description coverage is 0%, so the description must compensate. It explains that 'receipt' is the object returned by paid verify tools and that 'affiliate_id' is accepted but inert on this free call. This adds meaning beyond the bare schema, though it does not detail the internal fields of the receipt object.

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 this tool 'verify[ies] a signed verdict RECEIPT', using a specific verb and resource. It distinguishes itself from paid verification siblings (quick_verify, grounded_verify, pro_verify) by explicitly positioning it as a free, stateless audit trail/second opinion for receipts returned by those paid tools.

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 clearly says to use this tool by passing 'the receipt object returned by any paid verify tool' and frames it as a 'free discovery route' for proving a result or catching tampering. It implies when not to use it (not for initial verdicts), but does not explicitly name alternatives like 'use quick_verify for initial verification'.

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