Hermes Plant — Agent Commerce Assurance

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

The description adds useful behavioral context beyond annotations: determinism, cost, and the three decision outcomes. Annotations already declare idempotentHint=true and destructiveHint=false, and the description aligns with these, so there is no contradiction.

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: the first front-loads cost and purpose, the second defines deterministic behavior and decision outputs. Every word earns its place; 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?

Given the tool's complexity (16 params) and the presence of an output schema, the description adequately conveys cost, determinism, and the three decision branches. It could explicitly state that no action is executed, but 'preflight' and 'scores' make this sufficiently clear.

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 structured parameter descriptions already document all 16 parameters. The tool description adds no extra parameter-level semantics, which is acceptable given the schema's completeness.

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 specifies a concrete action: deterministically score a consequential action and return the exact next call (proceed, request full DestructGuard evidence, or run the complete Action Safety workflow). It clearly identifies the tool as a cheap preflight gate and differentiates it from the full Action Safety workflow.

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 establishes clear usage context through cost ('$0.01 over x402 or free-tier quota') and role ('quick gate', 'preflight'), implying it should be used before committing to expensive/full workflows. However, it does not explicitly name sibling alternatives or state when not to use it, so it lacks full alternative 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?

Beyond the annotations (readOnlyHint false, destructiveHint false, idempotentHint true), the description adds important behavioral context: it is a paid workflow ($0.25 or free-tier quota), includes conditional triage triggered by high/critical risk, produces a signed receipt and 30-day record, and explicitly warns that triage does not imply human approval. This gives the agent a clearer picture of side effects and caveats.

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, with the purpose and key components front-loaded in the first sentence. It efficiently conveys the workflow, cost, and a critical caveat without wasted words. The colon structure organizes the components cleanly.

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 (16 parameters, output schema present, multiple workflow stages), the description provides a solid high-level summary. It explains the conditional triage, payment options, and the duration of the status record. The presence of an output schema covers return-value details, so the description does not need to list them. Minor gaps include lack of explicit description of the decision values or failure modes, but overall it is 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?

The input schema has 16 parameters with 100% description coverage, so the baseline is 3. The tool description does not add parameter-level meaning beyond what the schema already provides, but it also does not need to given the high schema coverage. The high-level workflow description indirectly references some concepts (e.g., evidence, triage) but does not map them to specific parameters.

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 identifies the tool as 'Complete AI agent action safety workflow' and enumerates the specific steps it performs: DestructGuard evidence, conditional ReviewQueue triage, decision, signed receipt, and a 30-day status record. This distinguishes it from the sibling 'action_safety_quick_gate' by emphasizing completeness, and the verb 'workflow' implies execution.

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 via the 'complete workflow' phrasing and the cost/payment context, suggesting it is the full pipeline as opposed to faster or partial alternatives. However, it does not explicitly state when to use this tool versus siblings like 'action_safety_quick_gate' or sub-step tools, nor does it provide exclusion criteria.

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 idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: the paid nature ($0.05 per call), the HMAC-signed record mechanism, and the intended loop usage. These are informative and do not contradict annotations, though failure modes and rate limits are not disclosed.

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 and front-loaded with the tool name and cost. Every sentence serves a purpose: the first defines the action and output, the second provides usage guidance and references verification. No wasted words, appropriately sized for the tool's complexity.

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 complex tool with 14 parameters and nested objects, the description gives the essential context: core function, cost, usage pattern, and verification path. It does not mention required parameters (protocol, subject, intent) or the API key, but the schema covers these. Output schema exists, so return value details are unnecessary. The description is complete enough for initial tool selection.

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 fully documents all 14 parameters. The description adds minimal parameter context, only hinting at 'optional settlement outcome' and mentioning 'binding hash, policy verdict, findings' which loosely map to the policy/outcome fields. This is sufficient but not enhanced beyond the baseline for complete schema coverage.

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 action: 'bind one x402 payment intent or MCP tool call to a canonical HMAC-signed record.' It identifies the resource (payment intent or tool call) and the result (signed record), and differentiates itself from sibling assurance_verify by referencing the 'free verify endpoint' for third-party checking.

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 instructs 'Loop it after every payment or tool call to build a tamper-evident audit trail,' giving clear when-to-use guidance. It also implies an alternative verification path via the 'free verify endpoint,' though it does not name the sibling tool assurance_verify directly or state explicit exclusion criteria.

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 and idempotentHint. The description adds valuable behavioral detail about the server-side recomputation and the returned validation flags, without contradicting the annotations. It doesn't however discuss failure modes or rate limits, but the bar is lower due to 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?

Two sentences, front-loaded with purpose and method, no filler. Every word serves a 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?

Given the tool's moderate complexity, an output schema exists, and the description effectively covers how the verification works and when to use it. It's self-sufficient for invoking 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 100%, so baseline is 3. The description doesn't add parameter-level nuance beyond the schema's generic object descriptions, but the schema itself adequately defines the two parameters.

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 action — verifying a Hermes-signed assurance record — and details the method (recomputing canonical hash and HMAC). It clearly distinguishes itself from sibling tools by explicitly referencing assurance_attest as the producer.

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 guidance on when to use: 'Use it to audit attestations produced by assurance_attest without trusting the agent that produced them.' It does not mention alternatives like evidence_verify, but the context is clear and unambiguous.

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 idempotent, non-destructive, but not read-only. The description adds that it is 'x402-paid, $0.25' and 'deterministic', disclosing the payment side effect and predictable calculation behavior. 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?

Two sentences, front-loaded with the tool name and payment requirement, then concise mode descriptions. No filler or redundant restatement of schema properties.

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?

Covers both modes, the payment mechanism, and key input requirements. Output schema and 100% schema coverage fill in the remaining details. Slight gap: it doesn't explicitly state that bond mode requires either price or yield, but the price<->yield notation implies 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?

Schema coverage is 100%, so baseline is 3. The description adds mode-selection semantics by specifying which parameter combination triggers loan mode, and implies price<->yield either/or usage for bond mode, which is not explicit in the 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 clearly states a specific purpose: deterministic fixed-income and loan analytics, with distinct bond mode (solving price/yield, duration, convexity) and loan mode (amortization schedule). This differentiates it from sibling tools like options_price or cashflowlens_analyze.

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 tells when to use bond mode vs loan mode by specifying required inputs (principal+annualRate+termMonths for loan mode). It doesn't explicitly exclude alternatives, but the mode-specific instructions provide clear usage context.

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 (idempotent, non-destructive), the description adds meaningful context: it is x402-paid at $0.20, and it is deterministic. This discloses cost and result reliability, which is valuable 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 description is just two sentences, front-loaded with the tool name and cost, then a dense list of capabilities. Every clause earns its place; no fluff or repetition.

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 rich input schema and presence of an output schema, the description covers the essential context: what the tool computes, that it is paid, and that it is deterministic. It could have mentioned idempotency, but annotations already cover that.

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 explains each parameter thoroughly. The description does not add parameter-level detail, but it also does not need to; it correctly references the cashflow series without duplicating schema 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 names a specific set of analytical outputs (NPV, IRR, XIRR, DCF, MOIC/DPI/TVPI, payback period) tied to a concrete resource (cashflow series). It clearly differentiates from sibling tools by stating it is for valuation and return analysis rather than estimation.

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 says 'Use for valuation and return analysis instead of letting the model estimate,' which gives clear usage direction. It does not name sibling exclusions, but the context is sufficient for an agent to know when to select 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?

Annotations already cover idempotent and non-destructive behavior. The description adds useful context: 'Deterministic', 'x402-paid, $2.00', and 'cross-checked', which inform the agent about consistency, cost, and validation. It does not contradict annotations, and the added behavioral details go beyond what annotations provide.

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 the tool name and price, and every clause adds essential information. No redundant wording or fluff.

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 (12 params, nested objects), the description covers the core purpose, composition, and pricing. With output schema present, return values need not be explained. It lacks explicit error/rate-limit context, but the description is complete enough for selection and 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 every parameter already has a description. The tool description adds high-level grouping (DCF, returns, waterfall) but no additional parameter-specific detail. Baseline 3 is appropriate since the schema carries the parameter load.

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 function: 'full deal underwrite in a single call' with specific outputs (DCF valuation, fund returns, LP/GP waterfall, sensitivity). It distinguishes from siblings by explicitly naming CashflowLens and WaterfallLens as components it combines, making its unique value obvious.

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 signals when to use this tool by positioning it as the 'flagship' that combines CashflowLens + WaterfallLens, implying it is preferred for comprehensive underwriting. However, it does not explicitly state when to use the individual lens tools instead (e.g., for focused analysis), so exclusions are implied rather than stated.

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 goes beyond annotations by stating 'deterministic' and 'pure function, no DNS', which are behavioral traits not fully captured by annotations (idempotentHint, destructiveHint). It also discloses the x402-paid cost. This adds meaningful context about side effects (payment) and external dependencies (no DNS). No contradiction with annotations, though 'pure function' could be interpreted as read-only while readOnlyHint is false, the description qualifiers make it clear the computation is deterministic, not necessarily free of payment 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?

The description is extremely concise: two sentences, front-loaded with the tool name, pricing, and core functionality. Every word contributes value, with no filler or repetition. It is well-structured for quick agent consumption.

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 and fully described parameters, the description adequately covers the high-level purpose, behavior, and cost. It does not explain the payment flow or how to use apiKey vs. x402, but those are detailed in the schema. The description is sufficient for an agent to understand what the tool does and decide if it fits the use case, though a note about the batch sibling or free-tier option would increase 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?

All 13 parameters have rich descriptions in the schema (100% coverage), so the baseline is 3. The description adds little about parameters themselves, only naming output categories. It does not clarify the specific parameter semantics beyond what the schema already provides, so it neither compensates nor detracts.

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 identifies the tool as an email/contact quality scorer, listing specific outputs (validity, deliverability score, disposable/role/free classification, typo suggestion). It uses a specific verb ('scorer') and resource ('email/contact'), making the purpose clear. However, it does not explicitly distinguish itself from the sibling tool 'emailguard_validate_batch', leaving ambiguity about single vs. batch validation.

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 implicit usage context: 'Pure function, no DNS' suggests it is a fast, deterministic choice suitable for single email checks without network dependency. It also notes it is x402-paid, hinting at cost considerations. However, it does not explicitly state when to use this tool versus alternatives like the batch validator or free-tier key options, and no exclusions are mentioned.

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 adds substantial behavioral detail beyond the annotations: deterministic verdicts, preserving input order, stopping at the first 402 and marking the rest skipped, and quota per record. It also discloses auth needs (apiKey) and rate limits (250 records/mo). No contradictions with annotations; idempotentHint is supported by the deterministic verdict statement.

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 and front-loaded with the core purpose, then quota, then processing behavior. Every sentence adds critical information without fluff. It is concise yet highly informative for a tool with 10 parameters and an output schema.

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, the rich input schema, and the presence of an output schema, the description covers essential context: purpose, batch limit, quota, authentication, deterministic behavior, and failure semantics. It does not need to explain return values due to the output schema, and nothing important appears missing 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 description coverage is 100%, so baseline is 3. The description does not add significant parameter-level meaning beyond what the schema already provides; it repeats the quota/402 behavior but doesn't explain individual parameters further. It offers some business context about apiKey and records, but this is largely redundant with the schema descriptions.

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 function: 'Validate up to 20 emails in one tool call' and enumerates the specific verdict components (validity, deliverability score, disposable/role/free classification, typo suggestion, canonical normalization). It also distinguishes itself from the sibling tool by emphasizing batch validation with a max of 20 email records.

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 establishes clear usage context: batch validation for up to 20 emails, with quota implications (free apiKey, 250 records/mo) and failure behavior (stops at first 402, marks rest skipped). However, it does not explicitly contrast with the single-email sibling 'emailguard_validate' or state when not to use this tool, 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?

The description discloses the cost ('x402-paid, $0.05') and the return categories (verified / needs_review / rejected / insufficient_evidence), which adds value beyond the annotations. Annotations already indicate idempotent and non-destructive behavior, so the description doesn't need to repeat those. It doesn't detail billing side effects beyond cost, but given the annotations cover safety, this is sufficient.

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 the core purpose and cost, followed by a compact list of verification targets and outcome categories. Every phrase conveys relevant information, and there is no redundancy or filler. It is dense but well-organized for quick scanning.

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 the core function, the types of artifacts, the checks performed, and the expected outcome values. An output schema exists, so the description doesn't need to explain return values in depth. Given the tool's complexity (12 parameters, nested objects), the description is sufficient for an agent to understand when and why to invoke it, though it doesn't elaborate on policy construction—which is covered by the schema.

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 parameters are fully documented in the schema. The description adds context about artifact types (x402_challenge, x402_receipt, etc.), which aligns with the 'artifacts' parameter but doesn't introduce new meaning beyond the schema. The baseline of 3 is appropriate since the schema carries the 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?

The description clearly states the tool's purpose: 'verify an agent-commerce evidence bundle before trusting a paid result'. It names a specific verb (verify) and resource (evidence bundle), lists concrete artifacts (x402 challenge/receipt/policy-decision/service-response), and mentions specific checks (endpoint/price binding, freshness, hashes), making it distinct from generic verification 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 phrase 'before trusting a paid result' provides clear context on when to use the tool. It does not explicitly mention alternatives or exclusions, but the context is specific enough to guide an agent. No explicit comparison to sibling tools like assurance_verify, so it misses the 'when not to use' aspect, but the usage 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 already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds value by specifying the exact information returned (remaining quota, reset date, upgrade path), which is beyond what annotations provide. It doesn't mention troubleshooting or edge cases, but for a simple status check this is sufficient.

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, with the primary purpose front-loaded. The first sentence states exactly what the tool does; the second adds actionable context for users without a key. No wasted 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?

The tool has an output schema (not shown here), so return values need not be described. The description covers the purpose, the required parameter, and the alternative for keyless users, making it complete for a simple read-only operation.

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% for the apiKey parameter, with the schema already noting 'free-tier key (hp_free_...)'. The description repeats this format ('hp_free_ key') without adding new semantic meaning. Thus 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 clearly states the tool's function with a specific verb ('check') and the resource ('free API key's remaining monthly quota, reset date, and upgrade path'). It is unambiguous and distinguishes this tool from the listed siblings, none of which deal with free-tier key 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 explains when to use the tool (when you have a free API key) and provides explicit guidance for those who don't ('No key yet? POST an email to https://hermesplant.com/api/keys/free'). This serves as a clear when-to-use and when-not-to-use (since the tool requires an existing key).

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, so the safety profile is covered. The description adds that it returns URLs specifically, but it does not disclose potential errors or edge cases. With annotations covering safety, this is adequate but not rich.

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 sentence of eight words, front-loaded with the imperative verb 'Return'. Every word earns its place with 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?

Given the tool has no parameters, output schema exists, and annotations cover behavioral safety, the description sufficiently explains what the tool does and when to use it. It is complete for a simple read-only utility.

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 and the schema's description coverage is 100% (empty object). Per the rubric, a zero-parameter tool receives a baseline of 4, and the description does not need to compensate.

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 'Return' with a clear resource ('legal policy URLs') and context ('required before checkout'). This clearly distinguishes it from sibling tools like start_checkout and payment_policy_decide.

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 phrase 'required before checkout' explicitly indicates when the tool should be used, implying it should be called before initiating checkout. While it does not name alternative tools or exclusions, it provides sufficient timing context for an agent.

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 annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond the obvious get operation, such as error handling or permissions, so it doesn't provide additional transparency beyond the 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 a single, well-formed sentence that immediately states the action, resource, and parameter. It is front-loaded and contains no filler, scoring a 5.

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 getter tool with a single parameter, an output schema, and annotations indicating safety and idempotency, this short description is sufficient. It clearly communicates what the tool does, and the output schema covers return values, so the description is 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?

The schema has 100% coverage with the slug parameter described as 'Product slug from the catalog', and the description reinforces this by saying 'by slug'. The description adds no extra semantic detail beyond the schema, 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 uses the specific verb 'Get' with the resource 'single product' and the unique identifier 'slug', making it clear this is a point lookup. This distinguishes it from sibling tools like list_products which would handle list 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 usage when you need one product by slug, but does not explicitly state when to use it versus alternatives like list_products or other product-related tools. There are no exclusions or alternative tool names mentioned, so it earns a 4 for clear context without 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be safe. The description adds the 'live' qualifier, indicating the manifest is fetched in real time, and enumerates the specific data elements (paid endpoint prices, Bazaar metadata, buyer policy checks). It does not mention potential network latency or rate limits, but for a read-only idempotent operation this is adequate.

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 sentence of 12 words, front-loaded with the verb and resource, and each phrase adds specific value (live, paid endpoint prices, Bazaar metadata, buyer policy checks). There is no waste 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?

The tool is simple (no parameters, read-only, idempotent) and has an output schema, so the description does not need to explain return structure. The description fully communicates what the tool does, and the annotations cover safety and idempotency. For a zero-parameter manifest fetch, this is 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?

The input schema has zero parameters, so the description has no parameter explanations to provide. With 0 parameters, the baseline score is 4, and the description does not need to compensate for any schema gaps.

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 'Return' and a resource 'the live x402 manifest', and it lists the contents (paid endpoint prices, Bazaar metadata, buyer policy checks). This distinguishes it from sibling tools like get_checkout_policies or payment_policy_decide, which serve different purposes.

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 by naming what is returned, but it does not explicitly state when to use this tool versus alternatives from the sibling list, such as purchase_with_x402 or start_checkout. It has no explicit exclusions or alternative guidance, relying on the agent to infer based on the manifest-focused purpose.

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 product scope ('active products', 'Hermes Plant catalog') but does not disclose any additional behavioral traits like pagination, ordering, or filtering. This is consistent with annotations and acceptable for a simple list 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 a single sentence that immediately states the action and object. It is concise, front-loaded, and contains 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?

The tool has no parameters, has an output schema, and annotations cover safety. The description is sufficient for an agent to understand when to invoke the tool and what to expect at a high 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?

The tool has zero parameters, so the schema provides full coverage. The baseline for 0 params is 4, and the description does not 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's function: 'List active products' from a specific catalog. The verb 'List' and resource 'active products from the Hermes Plant catalog' are specific, and the plural 'products' distinguishes it from the sibling 'get_product'.

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 context is clear: use this tool to retrieve a list of active products. It does not explicitly mention alternatives like 'get_product' for single-product retrieval, but the naming and description make the use case obvious.

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 adds value beyond annotations by disclosing the x402 payment requirement and cost ($0.05), as well as the return format ('per-tool findings and fixes'). It does not explain potential side effects beyond payment, and it does not contradict the 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 a single sentence that front-loads the tool's name, payment/cost, and core function. Every phrase earns its place; no filler or redundant 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 tool's complexity (13 params, output schema, annotations), the description covers the essential usage scenario, pricing, and output highlights. It lacks an explicit mention of the input format (a manifest), but that is covered by the schema, so the description is sufficiently 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?

With 100% schema description coverage, every parameter already has a detailed description. The tool description adds no additional parameter-specific meaning beyond the payment model, 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 ('score'), resource ('MCP server manifest'), and outcome ('security risk before install', 'with per-tool findings and fixes'). It also lists concrete risk dimensions (destructive tools, over-broad scopes, weak auth, egress), clearly distinguishing it from sibling scoring tools like score_destructguard_command or walletguard_score.

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 phrase 'before install' provides a clear temporal context for when to use this tool. It implies the alternative of analyzing a server post-install or using a different tool, but does not explicitly name alternatives or exclusions, which keeps it at a 4 rather than 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?

The description discloses that the tool is x402-paid at $0.30, indicating a required payment or quota, which complements the annotations' readOnlyHint=false. It also states the computation is deterministic and lists the broad output scope, adding useful context 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 a single, information-dense sentence that front-loads the brand and cost, then succinctly enumerates the function and outputs. No redundant words or content.

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 the tool's core purpose, pricing model, and output breadth, while the input schema and output schema (present) handle parameter details. Given the large parameter count, the description appropriately focuses on the main function and leaves technical details to the schema.

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?

With 100% schema description coverage, each parameter is already described. The tool description adds an overview of what the calculation includes (e.g., dividend yield) but does not elaborate on individual parameters, so the schema carries the primary semantic load.

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 identifies the tool as a Black-Scholes price and Greeks calculator for European options, listing specific outputs (delta, gamma, vega, theta, rho) and inputs (dividend yield). It distinguishes itself from sibling tools like bond_analyze or cashflowlens_analyze by focusing specifically on options pricing.

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 for European option pricing but does not explicitly state when to use this tool over alternatives or when not to use it. The 'x402-paid' notation and cost hint at a monetized service, but no exclusions or alternative recommendations are 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 cost ($0.05), determinism, and the specific checks (resource binding, replay readiness, PII leakage, spend limits) which go beyond the annotations (idempotent, non-destructive). This adds substantial behavioral context without contradicting any annotation.

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 sentences with the tool name and cost front-loaded, followed by the action and key checks. No filler or redundancy; every sentence 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?

For a tool with 21 parameters, nested objects, and an output schema, the description adequately covers the decision outcome, cost, usage context, and relationship to sibling tools. The output schema handles return values, so no relevant gap remains.

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 adds meaning by linking the checks to parameter categories (network, payTo, facilitator, buyerPolicy, etc.), which helps agents map inputs to decision logic.

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 ('preflight'/'decide') and resource ('x402 payment'), explicitly stating the outcome (allow/deny/needs_review) and listing the checks performed. It distinguishes itself from siblings like assurance_attest by clarifying its preflight 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 instruction 'Loop it over every payment' provides explicit when-to-use guidance, and 'pair with assurance_attest for a signed record' names a complementary tool. However, it lacks explicit when-not-to-use conditions or 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?

The description adds behavioral context beyond the annotations: 'x402-paid, $0.15' discloses cost and payment method, and 'deterministic' reinforces idempotency (which annotations also hint at). It does not contradict the annotations; it enriches them with pricing and determinism details.

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 packs product name, cost, purpose, and key metrics without redundancy. Every element earns its place and it is immediately understandable.

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 well covered by a detailed input schema, output schema, and annotations. The description adds the critical missing context: cost, determinism, and the specific metrics calculated. Together, the structured data and description give a complete picture for selection and 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?

The input schema has 100% parameter description coverage, so the schema already thoroughly documents each parameter. The tool description does not add meaning beyond the schema; it mentions 'holdings' and metrics, but these are already present in the schema. 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 uses a specific verb ('scoring') and clearly identifies the resource ('portfolio risk') with a defined scope ('from holdings'). It lists concrete metrics (volatility, Sharpe, max drawdown, concentration, diversification), distinguishing it from sibling tools like walletguard_score or mcp_risk_score.

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 the use case ('portfolio risk scoring from holdings') and notes it is x402-paid, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of alternative tools or conditions, so guidance is only implicit.

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 tool may initially return a 402 challenge, requiring the caller to 'sign and retry with PAYMENT-SIGNATURE' – a behavioral trait not fully captured by annotations. It also notes the two possible returns (402 challenge or fulfillment JSON). Annotations already indicate non-readOnly, so the description adds context about the protocol flow, though it doesn't mention financial side effects explicitly.

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 the core action and output, followed by a compact workflow. Every sentence adds essential information without redundancy or 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?

The description sufficiently explains the x402 flow, including prerequisites and retry behavior, for a complex tool with 11 parameters and an output schema. It doesn't elaborate on parameter specifics (rightly left to the schema) or the manifest fields, but the core operational context is present. Slightly more coverage on what 'one-time product' implies could earn a 5.

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 detailed parameter descriptions, so the description adds little parameter-level meaning. The only tie is referencing PAYMENT-SIGNATURE, which the schema already explains in the paymentSignature parameter. No additional parameter semantics are provided; this is a baseline 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 tool's function: 'Purchase a one-time product via x402 (returns 402 challenge or fulfillment JSON)'. This specifies a verb (purchase), a resource (one-time product), and the mechanism (x402). It distinguishes itself from sibling tools like get_x402_manifest or list_products by explicitly being the purchase action.

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 explicit usage prerequisites: 'Call get_x402_manifest first, verify method/path/network/amount/payTo, then sign and retry with PAYMENT-SIGNATURE.' It clearly indicates the workflow and when this tool is appropriate (after the manifest is obtained). It does not explicitly mention when not to use it or alternatives, so it misses the top tier.

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=false, destructiveHint=false, and idempotentHint=true. The description adds the important context that this is an x402-paid service requiring payment and a prior manifest check, which is not captured by annotations. However, it does not disclose potential side effects, telemetry, or error behaviors beyond the payment flow.

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: the first states the core purpose, the second gives a compact three-step usage sequence. It is front-loaded, efficient, and free of 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?

The tool has an output schema, so return values are covered. The description provides crucial integration context (call get_x402_manifest first, verify policy, retry with payment signature) that fits the broader workflow among siblings. However, it lacks guidance on when not to use this tool or how to handle payment failures, but the structured schema and sibling context make it reasonably 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 all 15 parameters are documented with descriptions. The description itself adds a workflow hint about using the x402 payment signature, but does not explain each parameter beyond what the schema already provides. Thus it meets the baseline for high coverage but does not significantly enhance parameter understanding.

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 identifies the tool as scoring a command/action via the DestructGuard service, distinguishing it from generic scoring tools by referencing x402 payment and the specific DestructGuard brand. It also mentions the prerequisite call to get_x402_manifest, which further clarifies 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?

It explicitly instructs to call get_x402_manifest first to verify price and buyer policy, then retry the 402 challenge with an x402 payment signature. This provides a clear workflow and prerequisite, though it does not explicitly name alternative tools or exclusion scenarios.

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 this is a non-read-only, non-idempotent operation with potential open-world effects. The description adds no additional behavioral context (e.g., whether a charge occurs immediately, if a session URL is returned, or if the operation is reversible). It only restates the basic action.

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 with no fluff or redundant wording. Every word adds meaning, making it highly concise and well-structured.

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 low complexity (one required parameter, output schema present, annotations provided), the description covers the essential purpose. It does not detail return values or side effects, but the output schema exists and the context signals are sufficient for a simple checkout initiation 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%: the slug parameter is documented as 'Product slug to purchase', and the tool description references 'product slug', reinforcing the same meaning. The description adds no new information beyond the schema, serving as a baseline adequate case.

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 ('Start') with a clear resource ('Stripe checkout session') and a scoping parameter ('for a product slug'). It unambiguously identifies the tool's function and distinguishes it from siblings like get_checkout_policies or list_products.

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 core usage is implied: use when you want to start a checkout for a given product slug. However, there is no explicit guidance on when not to use this tool or how it compares to related payment tools like payment_policy_decide or purchase_with_x402, leaving room for ambiguity.

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 adds behavioral context beyond annotations: this is a paid x402 flow that requires a payment signature and a 402 retry. Annotations already mark it idempotent and non-destructive, so the description supplements rather than contradicts.

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, front-loaded with the action, and each sentence delivers necessary operational guidance without filler. The workflow is compact and easy to parse.

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 15 parameters and an output schema, the description captures the essential workflow (fetch manifest, verify policy, retry with payment). It does not enumerate optional fields, but the schema already covers those, leaving only minor gaps around alternative payment paths like apiKey.

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?

Input schema coverage is 100% with all 15 parameters described, so the description does not need to restate them. It does helpfully tie the 'x402 payment signature' to the payment flow, but adds no per-parameter semantics beyond the 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 uses specific verb+resource: 'Submit a command/action to the x402-paid ReviewQueue agent service.' It clearly distinguishes this from sibling payment/x402 tools like get_x402_manifest and purchase_with_x402 by naming the ReviewQueue service.

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 usage guidance is provided: 'Call get_x402_manifest first, verify the ReviewQueue price and buyer policy, then retry the 402 challenge with an x402 payment signature.' This gives an ordered workflow and prerequisites, effectively telling the agent when and how to use this tool.

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 adds behavioral context beyond annotations (e.g., deterministic, x402-paid, reliance on caller-provided evidence). However, the claim 'x402-paid' is misleading because the schema documents an apiKey alternative that works without an x402 wallet, undermining the accuracy of the payment disclosure. Annotations already provide idempotentHint=true, which aligns with 'deterministic', but the payment description is incomplete.

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: two sentences that front-load the tool name, cost, and core function. There is no wasted wording, and it efficiently conveys the essential behavior and output.

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?

While an output schema exists and the description mentions the key outputs, it omits the alternative payment method (API key) that the schema supports. Given the tool's complexity (15 parameters, payment options), the description is incomplete and could mislead an agent into thinking x402 payment is mandatory. The core purpose is clear, but the payment ambiguity prevents a higher score.

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 all parameters are documented in the schema. The description adds value by grouping key context categories (sanctions, exposures, labels, fund sources), which helps identify important inputs, but it does not provide additional detail beyond the schema's parameter descriptions. Baseline 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 clearly identifies the tool as a deterministic wallet AML/compliance risk scorer with a specific verb and resource. It specifies the output (0-100 risk score, level, evidence-backed findings), distinguishing it from sibling tools like portfolioguard_score (portfolio risk) and mcp_risk_score (generic risk).

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 indicates the tool should be used when a wallet AML risk score is needed from caller-provided context, naming the key evidence types (sanctions, exposures, labels, fund sources). It does not explicitly exclude alternative tools or provide when-not guidance, so it lacks the full explicit comparison expected for 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?

The description adds context beyond annotations: it is x402-paid at $0.30 and deterministic. This is useful. However, it does not disclose potential side effects, error handling, or whether the tool requires specific inputs beyond the required ones. Given annotations already indicate idempotentHint=true and destructiveHint=false, the added behavioral context is moderate but not comprehensive.

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, well-structured sentence that leads with the tool's name and cost, then states the purpose and outputs. Every word earns its place; there is no fluff or repetition. It is appropriately sized for the tool's complexity.

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 explains what the tool does and what it returns, but it lacks usage context—when to apply it, what scenarios it is designed for, or how it relates to sibling tools. Since an output schema exists, the absence of return-value details is acceptable. However, with 17 parameters and a niche financial function, more contextual guidance would be helpful for an agent to decide 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?

Schema description coverage is 100%, so the baseline is 3. The description names key waterfall concepts (return of capital, preferred, catch-up, carry) which map to parameters like contributedCapital, preferredRate, catchUpPercentage, and carryPercentage, but it doesn't explain any parameter beyond what the schema already states. It does not compensate for any gaps because there are none.

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 and resource: 'deterministic LP/GP distribution waterfall' — and enumerates the stages (return of capital, preferred, GP catch-up, carried-interest split) plus the outputs (exact split, per-tier breakdown, LP MOIC, effective carry %). This distinguishes it from generic financial tools and leaves no ambiguity about what the tool computes.

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 guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites, or exclusions. Sibling tools like cashflowlens_analyze or dealanalyzer_analyze might overlap, but the description makes no attempt to differentiate or direct the agent to the appropriate tool.

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