Hermes Plant

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds value by explaining the deterministic scoring and the three return call outcomes. It does not contradict annotations and provides additional context on cost and quota usage.

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 at two sentences, front-loading the core purpose and cost. Every word adds value; no redundancy 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 existence of an output schema and detailed parameter descriptions, the description provides sufficient context on the tool's core function and outcomes. It lacks details on error handling or prerequisites (like requiring an API key), but these are covered in the parameter 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 schema fully documents all 16 parameters. The description does not add any parameter-level information beyond what is in the schema, meeting the baseline for high 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 identifies the tool as a quick preflight gate that scores an action and returns a decision. It specifies the cost and distinguishes from siblings like action_safety_run by calling it a 'quick gate' and listing the three possible outcomes.

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

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

The description implies this is a lightweight, cheap alternative to the full Action Safety workflow, mentioning cost and free-tier quota. However, it does not explicitly state when to use this vs. tools like score_destructguard_command or action_safety_run, leaving some 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds value by disclosing cost ($0.25 over x402 or free-tier quota), the conditional triage for high/critical risk, and explicitly stating that triage does not imply human approval. No contradictions with annotations.

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

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

The description is extremely concise: two sentences that pack a lot of information (cost, workflow stages, caveat) with no fluff. Every sentence earns its place.

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 (16 parameters, output schema exists), the description provides a high-level overview that covers the workflow's purpose and key outputs (signed receipt, 30-day status record). It does not detail the output schema, but that is acceptable since the schema is present. Slightly more detail on the flow could improve completeness.

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

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

Schema coverage is 100% with descriptions for all 16 parameters. The description does not add additional parameter-specific meaning beyond the schema, 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 clearly states it is the "complete" workflow, listing key components like DestructGuard evidence and ReviewQueue triage. However, it does not explicitly differentiate itself from sibling tools such as action_safety_quick_gate or score_destructguard_command, which may partially overlap.

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 action_safety_quick_gate or submit_reviewqueue_request. There is no mention of prerequisites, exclusions, or context for selecting this tool over 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?

Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds significant context: the cost ($0.05, x402-paid), the binding behavior (HMAC-signed record), and the optional settlement outcome. No contradictions with annotations.

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

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

The description is concise with two sentences. The first sentence states the purpose and cost; the second provides the usage pattern. Every word earns its place, and it is front-loaded with the most critical 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 (14 parameters, nested objects), the description is somewhat brief. It covers the essential usage pattern but does not explain concepts like HMAC-signed record, the role of required parameters, or the output schema. With an output schema present, return values are covered, but more behavioral context would be beneficial for a complex 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 baseline is 3. The description does not elaborate on parameter details beyond the schema, but the schema itself provides sufficient documentation for each parameter. Thus, the description adds minimal value for parameter semantics.

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

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

The description clearly states it creates a signed receipt (assurance attest) for an agent action (payment or tool call), binding to an HMAC-signed record. It specifies the verb 'bind' and the resource 'HMAC-signed record', distinguishing it from siblings like assurance_verify.

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

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

The description explicitly says 'Loop it after every payment or tool call', providing clear usage context. It mentions the free verify endpoint as a counterpart, but does not explicitly exclude scenarios or state 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?

Description adds value beyond annotations (readOnlyHint, idempotentHint) by noting the tool is free, uses specific hash algorithm (hermes-stable-json-v1 + SHA-256), and returns two booleans (recordHashValid, signatureValid). 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 concise sentences that front-load the purpose. Every sentence provides essential information 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 presence of an output schema, the description adequately covers the tool's function, including the free nature and specific outputs. It is complete for a verification tool, though it could briefly mention the output schema's role.

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 elaborate on parameters beyond their context, but it implicitly connects 'record' and 'integrity' to the verification process. No additional parameter-level details provided.

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 verifies a Hermes-signed assurance record, recomputes hash and signature, and reports validity booleans. It distinguishes from sibling tool 'assurance_attest' by specifying it is used for auditing without trusting the producing agent.

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

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

Explicitly states 'Use it to audit attestations produced by assurance_attest', providing clear context for when to use. Does not specify when not to use, but the guidance is sufficient.

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 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?

Annotations indicate idempotentHint=true and destructiveHint=false; description adds 'deterministic' and pricing ('$2.00'). It mentions payer info 'stored only as a hash' but does not fully clarify side effects beyond billing or storage. Overall, useful 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?

Two sentences front-load key purpose and distinction. Every sentence adds value with 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?

For a complex tool with 12 parameters and nested objects, the description provides a solid overview. Output schema exists, so return details are omitted. Minor gaps include prerequisites or error conditions, but overall completeness is good.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds high-level context about outputs but does not significantly enhance parameter meaning. 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 explicitly states the tool performs 'full deal underwrite in a single call' and lists specific outputs (DCF valuation, fund returns, waterfall, sensitivity). It clearly distinguishes from siblings by noting it 'Combines what CashflowLens + WaterfallLens do, cross-checked.'

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 when to use this tool (for a full analysis) vs. siblings (CashflowLens, WaterfallLens) but does not explicitly state when not to use it or alternative scenarios. The guidance is clear but 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 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 (idempotentHint=true, destructiveHint=false) are supplemented by description stating deterministic verdicts, order preservation, and quota handling. No contradictions, but could mention if it modifies or stores any data beyond quota tracking.

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 core functionality in the first sentence and behavioral details in the second. Every sentence adds value, no 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 output schema exists (so return values not needed in description), the description covers purpose, usage, and key behaviors (max 20, quota, order). Minor gaps: no mention of error handling beyond 402, 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 baseline is 3. Description adds contextual value: explains apiKey source, records max, and batch behavior (quota exhaustion, order). This improves understanding beyond 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 it validates up to 20 emails per call and lists the specific verdicts (validity, deliverability score, disposable/role/free classification, typo suggestion, canonical normalization). The title also contrasts with the sibling tool 'emailguard_validate', indicating batch vs single use.

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: for batch validation with up to 20 emails, and mentions quota consumption and behavior on quota exhaustion (stop at 402, mark rest skipped). It implicitly distinguishes from the single-email sibling but does not explicitly state 'use this for multiple emails, use emailguard_validate for single'.

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 idempotentHint annotation (true), the description lists the verification checks (endpoint/price binding, freshness, hashes, leakage) and the possible return statuses (verified, needs_review, etc.). It also mentions the cost ($0.05), adding transparency. It does not describe error conditions but the annotations cover idempotency.

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, dense paragraph that front-loads the core action and includes essential details. It is concise without being overly terse, though a slight restructuring could improve readability.

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 (12 params, nested objects, output schema), the description covers the high-level purpose, verification logic, and return types. It does not explicitly mention authentication requirements, but the schema's apiKey parameter description handles that. Overall, it provides sufficient context for an agent 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 coverage is 100% with descriptions for all 12 parameters. The description does not add extra meaning beyond the schema; it merely lists artifact types. Baseline 3 is appropriate as the schema carries the parameter semantics.

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

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

The description clearly states the tool verifies an 'agent-commerce evidence bundle before trusting a paid result', specifying the resource and action. It distinguishes itself from sibling tools like assurance_verify by focusing on x402 paid results and listing specific artifact types (challenge, receipt, etc.).

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 context on when to use the tool ('before trusting a paid result'), but does not explicitly exclude alternatives or state when not to use it. The context is strong enough for an agent to infer 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 read-only and idempotent. Description adds specific behavioral traits: returns quota, reset date, upgrade path, confirming safe read operation.

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, followed by usage instruction. No extraneous 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?

Given output schema exists, description sufficiently explains return values and usage. Covers all necessary context for a simple status check.

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

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

Schema covers apiKey 100% with description. Description adds value by specifying key prefix format and usage context 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?

Description clearly states the tool checks a free API key's remaining quota, reset date, and upgrade path. Specific verb 'check' and resource 'free API key status' distinguish from sibling analysis 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?

Explicitly instructs to pass hp_free_ key as apiKey and provides alternative action for users without a key (POST to URL). No direct mention of 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?

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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that the tool is 'deterministic' and produces 'allow/deny/needs_review' with evidence-backed findings, giving useful behavioral context 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?

Two sentences, front-loaded with purpose and key checks, no fluff. Every phrase earns its place.

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 and an output schema, the description covers the decision logic, checks performed, and usage pattern. The output schema handles return values, making the description complete for agent comprehension.

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 each parameter is documented. The description lists categories of checks (e.g., resource binding, amount vs expected price) but does not add detailed semantics beyond what the schema provides, earning 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 it is a preflight decision tool for x402 payments, specifying the verb 'decide' and the resource 'payment policy', and distinguishes it from sibling tools like assurance_attest by offering a paired usage.

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

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

Explicitly advises to 'Loop it over every payment' and to pair with assurance_attest, providing clear guidance on when and how to use it. Does not explicitly mention when not to use it, but the context implies it is for preflight before signing.

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.