Hermes Plant

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the tool is deterministic and x402-paid, providing some behavioral context beyond annotations, but does not disclose failure modes or rate limits beyond the apiKey parameter description.

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) and front-loaded with the title and payment info. It efficiently conveys key functionality, though could be slightly more structured to separate mode details.

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?

Despite 18 parameters, the description captures the core modes and essential parameters. The existence of an output schema mitigates the need to describe return values. The description adequately introduces the tool's purpose and input requirements for a complex analytics 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 coverage is 100%, so baseline is 3. The description adds value by clarifying which parameters belong to bond mode (price, yield, periods, etc.) and loan mode (principal, annualRate, termMonths), aiding the agent in selecting the correct mode.

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 for fixed-income and loan analytics, with two distinct modes (bond and loan). It names specific calculations (price-yield, duration, convexity, amortization schedule), which distinguishes it from sibling tools like 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?

The description provides clear guidance on when to use bond mode (price/yield, duration, convexity) and loan mode (principal, annual rate, term), but does not explicitly mention when not to use or discuss alternatives 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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description discloses cost ($0.20, x402-paid), determinism ('deterministic'), and data handling ('stored only as a hash' for payer parameter). These add meaningful behavioral context not captured in 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-sentence description with no redundancy. Every sentence serves a purpose: first lists output metrics and pricing, second gives usage guidance. Front-loaded with key 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?

For a complex tool (14 params, nested objects, output schema exists), the description covers purpose, key outputs, and usage direction. The existing output schema reduces need to describe return values. A minor gap is not elaborating on payment mechanism, but schema covers apiKey and xPayment.

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 tool description does not elaborate on parameters beyond what the schema provides. It adds no new semantic meaning for individual 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?

Description clearly states verb and resource ('deterministic NPV, IRR, XIRR, DCF valuation, MOIC/DPI/TVPI, and payback period from a cashflow series') and distinguishes from model estimation ('Use for valuation and return analysis instead of letting the model estimate'). Among siblings like bond_analyze, it stands out as the cashflow return calculator.

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?

Description explicitly says 'Use for valuation and return analysis instead of letting the model estimate,' providing direct context on when to prefer this tool over letting the model approximate. However, it does not specify when not to use it or name alternative tools for different use cases.

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?

Discloses paid nature (x402-paid, $2.00) and determinism, adding value beyond annotations. Does not cover error handling or rate limits, but annotations provide idempotency and non-destructive hints.

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 key outputs and cost. Every sentence adds unique 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?

Given high complexity and available output schema, description covers core functionality, related tools, and payment requirement. Lacks explicit prerequisites or limitations, but overall adequate.

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 description adds limited additional meaning. Groups parameters logically by mentioning DCF, returns, waterfall, but doesn't detail individual param semantics beyond 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?

Clearly states verb 'underwrite' and resource 'deal', lists specific outputs (DCF valuation, fund returns, waterfall, sensitivity). Distinguishes from siblings by noting it combines CashflowLens and WaterfallLens.

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?

Implicitly suggests using this for full underwriting vs. piecemeal tools (CashflowLens, WaterfallLens). No explicit when-not-to-use, but context is clear.

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

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

The description adds value beyond annotations by stating it is a 'pure function, no DNS' and 'deterministic,' aligning with idempotentHint. It also discloses payment details and cost ($0.02). Annotations already provide idempotentHint and destructiveHint=false, so the description enhances understanding.

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 key purpose and qualities. It includes pricing, deterministic nature, and output types without extraneous 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?

Given the tool's complexity (13 parameters, output schema present), the description covers the essential purpose and behavioral traits. It lacks details on error handling or rate limits but the idempotentHint and schema compensate. Overall, it provides sufficient context for an AI agent.

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, the schema already documents all 13 parameters. The description does not add extra meaning to individual parameters but summarizes the overall output. Baseline 3 is appropriate as the description provides general context without repeating parameter details.

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: 'deterministic email/contact quality scorer' with specific outputs like validity, deliverability score, disposable/role/free classification, and typo suggestion. It distinguishes itself from sibling tools which are financial/analytical, making its function unique.

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 email validation but lacks explicit guidance on when to use vs alternatives. It mentions pricing and payment methods but no exclusions or alternative tool recommendations. The sibling tools are unrelated, so the gap is minor but still present.

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; description adds that it returns required legal URLs, providing useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb and object, zero 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?

Given zero parameters and output schema present, description is complete for a simple retrieval 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?

No parameters, schema coverage 100%. Baseline 4 as per calibration; description has no need to add param info.

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?

Description uses specific verb 'Return' and resource 'legal policy URLs' with clear context 'required before checkout'. Distinguishes from sibling 'start_checkout' as a preparatory step.

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?

Context implies use before checkout, but no explicit when-to-use or comparison with siblings like 'get_product' or 'start_checkout'.

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, indicating a safe read operation. The description adds no additional behavioral context such as rate limits, side effects, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no unnecessary words. Every word 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 simple retrieval tool, the description covers the core functionality. An output schema exists, so return values are documented. Minor gaps include not mentioning error scenarios (e.g., slug not found).

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

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

Schema description coverage is 100% with the 'slug' parameter already described as 'Product slug from the catalog'. The description adds only 'by slug', which is redundant.

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 'Get' and specifies the resource 'single product' and the identifier 'slug'. This clearly distinguishes it from sibling tools like '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 description implies usage by slug but provides no explicit guidance on when to use this tool versus alternatives (e.g., list_products) or when not to use it.

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

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

Annotations already declare readOnlyHint:true and idempotentHint:true, which the description complements by specifying the live nature and contents. It adds value beyond annotations but does not discuss side effects or authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with front-loaded purpose, no wasted words. Every part of the sentence conveys useful 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 no parameters, output schema exists, and annotations cover safety, the description adequately explains the tool's output. However, it lacks usage context or prerequisites, slightly reducing 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?

There are zero parameters, and schema coverage is 100%. The description does not add parameter info because none exist, which is acceptable per baseline of 4.

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 clear verb 'Return' and specifies the resource 'live x402 manifest' with explicit details (paid endpoint prices, Bazaar metadata, buyer policy checks). It distinguishes this tool from siblings like 'get_product' or 'list_products' which operate on different resources.

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?

No guidance on when to use this tool versus alternatives like 'get_checkout_policies' or 'purchase_with_x402'. The description only states what it returns without context for selection.

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 description adds value by specifying that only 'active' products are listed, providing a behavioral filter beyond the structured metadata.

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 with no fluff, starts with the verb 'List', and effectively communicates the tool's purpose in few 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 no parameters, has an output schema, and annotations cover safety and idempotency. The description adds the context of 'active' and the catalog source, making it complete for a simple list 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?

With no parameters, schema coverage is 100% and baseline is 4. The description does not need to add parameter information as 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 the verb 'List', the resource 'active products', and the source 'Hermes Plant catalog', making it distinct from siblings like get_product which retrieves a single 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 description implies usage for retrieving a list of active products but does not explicitly mention when to use this tool versus alternatives such as get_product for individual product details.

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 (idempotentHint: true, destructiveHint: false) are consistent. The description adds critical behavioral info: cost ($0.05, x402-paid), and that it returns per-tool findings and fixes. 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?

Single sentence packed with all key information: purpose, cost, evaluation dimensions, and output type. No wasted words. Front-loaded with tool name and title.

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 full schema coverage, output schema existence, and rich annotations, the description provides sufficient context about input, cost, and output structure ('per-tool findings and fixes').

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 description doesn't need param details. It adds semantic context by mapping dimensions (destructive tools, scopes, auth, egress) to likely parameters (tools, permissions, authModel).

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

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

The description clearly states the verb 'score' and resource 'MCP server manifest' with specific security dimensions (destructive tools, over-broad scopes, weak auth, egress). It distinguishes from siblings like 'portfolioguard_score' by focusing on MCP server security 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 explicitly says 'before install', indicating timing. While it doesn't list alternatives, the unique domain (MCP server security) is clear among diverse siblings. No explicit when-not-to-use, but context is strong.

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?

Adds cost info ($0.30 x402-paid) and deterministic nature beyond annotations (idempotentHint true). No contradiction. Minor gap on payment failure behavior.

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 concise sentences, front-loaded with key info (cost, output, model), 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?

Describes outputs (Greeks, intrinsic/time value) despite output schema existing; covers payment model. Lacks edge case handling but adequate for typical use.

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 description adds no extra parameter meaning beyond what's in schema. 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?

Clearly states it computes Black-Scholes price and Greeks for European options, with specific outputs listed. Distinct from siblings like bond_analyze 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?

No explicit guidance on when to use or alternatives. Implied usage from pricing context but lacks when-not or sibling differentiation.

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

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

Description adds value beyond annotations by disclosing that the tool is deterministic, requires payment via x402 ($0.15 per call), and is not destructive. The idempotentHint and destructiveHint are consistent, but the cost and payment method are critical behavioral traits not in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with tool name, cost, and core output metrics. No extraneous information. Efficiently conveys key details.

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?

Description lists all output metrics and mentions 'per-rule findings'. With an output schema present, return values are adequately covered. The tool's complexity (paid, deterministic, specific metrics) is fully addressed.

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. Description mentions 'from holdings' but does not elaborate on other parameters (payer, apiKey, etc.). Since the schema fully defines them, the description adds marginal value but is not detrimental.

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?

Description clearly states the tool performs deterministic portfolio risk scoring from holdings, listing specific metrics (volatility, Sharpe, max drawdown, HHI, diversification, per-rule findings). The name and title align, and it distinguishes from siblings like mcp_risk_score by emphasizing determinism and specific metrics.

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?

Description implies use for portfolio risk scoring but does not explicitly state when to use this tool versus alternatives (e.g., mcp_risk_score). No exclusion criteria or context for when not to use it. Minimal guidance beyond the core function.

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

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

Description discloses the dual return type (402 challenge or fulfillment JSON) and hints at the retry mechanism. Annotations already indicate mutation (readOnlyHint=false), and the description adds context on the 402 protocol behavior.

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 actionable steps. Every sentence adds value without 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 complexity (11 parameters, output schema present), the description is sparse. It covers the core flow but lacks details on optional parameters and edge cases. With high schema coverage, it's adequate but not thorough.

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. Description does not add extra meaning beyond the schema, relying on individual parameter 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?

Description clearly states the verb 'Purchase' and resource 'one-time product via x402'. It distinguishes from sibling tools like get_product or get_x402_manifest, which are informational.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call get_x402_manifest first and outlines the verification and retry steps with PAYMENT-SIGNATURE, providing clear workflow 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?

The description adds context about the x402 payment flow and retry sequence, which is beyond the annotations (idempotentHint=true, destructiveHint=false). It does not contradict annotations, but could disclose more about what happens on failure or output expectations.

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-loading the purpose and immediately giving the usage sequence. No redundant 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?

Despite high complexity (15 params), the description covers the essential workflow and prerequisite. It assumes output schema documents return values, so it is mostly complete, though it could better explain the relationship to sibling tools like purchase_with_x402.

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 description does not need to add parameter details. It provides no additional parameter semantics beyond the schema, meeting the baseline.

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 scores a command/action using the DestructGuard service. It specifies the domain (x402-paid) and implies a workflow, but does not explicitly differentiate from sibling tools like 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 provides a usage sequence: call get_x402_manifest first, then verify price and policy, then use this tool to score, then retry the 402 challenge. However, it lacks explicit guidance on when not to use this tool or alternatives beyond the prerequisite.

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

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

Annotations indicate readOnlyHint=false and idempotentHint=false, implying state mutation. The description adds only 'Stripe checkout session' but omits details like side effects, prerequisites, or return behavior, providing minimal value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence (8 words) that immediately conveys the action and object. It is front-loaded and concise.

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 need not be described. However, given the context of 17 sibling tools including similar purchase-related ones, the description lacks guidance on prerequisites (e.g., authentication) and side effects. It is minimally complete but could be more informative.

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 fully describes the single parameter 'slug' as 'Product slug to purchase'. The description reinforces this but adds no additional meaning, so baseline 3 applies due to high 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 uses a specific verb ('start') and resource ('Stripe checkout session'), and clearly relates to purchasing via a product slug. It effectively distinguishes from siblings like get_checkout_policies and purchase_with_x402.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_checkout_policies or purchase_with_x402. It lacks any contextual cues for appropriate usage.

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 idempotency and non-destructiveness. The description adds the payment retry workflow and prerequisite, but does not disclose side effects, failure modes, or rate limits. The free-tier alternative is only in parameter descriptions.

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 efficient sentences: first states purpose, second gives essential workflow. No wasted words, front-loaded.

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 15 parameters and a payment-intensive workflow, the description explains the prerequisite but does not cover return values (though output schema exists) or the alternative free-tier usage. Adequate but with gaps.

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 adds workflow context for payment parameters but does not provide additional meaning 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 clearly states the tool submits a command/action to the x402-paid ReviewQueue agent service, specifying the resource and action. It distinguishes from siblings like get_x402_manifest and purchase_with_x402 by describing the 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 provides explicit instructions to call get_x402_manifest first and verify pricing/policy, then retry with payment signature. It gives clear prerequisites but does not contrast with alternative tools like apiKey-based free 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 declare idempotentHint=true and destructiveHint=false. The description adds 'deterministic' and 'x402-paid ($0.10)' cost context, providing useful behavioral details beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-loading cost and purpose with no wasted words. Efficient and scannable.

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 core behavior and output, but given 15 parameters and payment requirements, more context on optional parameter usage could enhance completeness. Still reasonably thorough.

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 summarizes parameter groups (sanctions, exposures, etc.), adding minimal value beyond existing 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 purpose: 'deterministic wallet AML/compliance risk scorer' and specifies inputs and outputs, distinguishing it from sibling tools like mcp_risk_score and portfolioguard_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 usage for wallet AML scoring with cost notice, but lacks explicit when-to-use, when-not-to-use, or alternative tool guidance.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: the tool is x402-paid ($0.30) and deterministic. It does not contradict annotations. It does not detail side effects beyond being non-destructive, but the cost and determinism are valuable additions.

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 tool name and cost. Every part is relevant; no unnecessary words. It efficiently conveys the tool's function and outputs.

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?

Despite 17 parameters and an output schema, the description effectively summarizes the tool's core function and key outputs (exact split, per-tier breakdown, LP MOIC, effective carry %). The output schema exists, so detailed return structure is not required. The description is complete for an agent to understand when to use the tool.

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

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

Schema description coverage is 100%, so the input schema fully documents each parameter. The description does not explain parameters further; it focuses on overall purpose and outputs. With high coverage, baseline 3 is appropriate.

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

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

The description clearly specifies the tool's function: a deterministic LP/GP distribution waterfall. It enumerates the key components (return of capital, preferred, GP catch-up, carried-interest split) and output details (exact split, per-tier breakdown, LP MOIC, effective carry %). This distinguishes it from all sibling tools, none of which are waterfall calculators.

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?

No explicit guidance on when or when not to use this tool versus alternatives. The description implies it is for waterfall calculations, but does not mention prerequisites, edge cases, or exclusions. Usage context is implied by the tool's niche purpose.

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