icme-preflight-mcp

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

With no annotations provided, the description carries the full burden, disclosing implementation (SMT solver), return semantics (SAT/UNSAT with extracted values), security properties ('Cannot be jailbroken'), and cost. It could improve by mentioning rate limits or error states, but comprehensively covers the verification mechanism and trust model.

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?

Information-dense with zero waste: sentence 1 states purpose, sentence 2 explains mechanism/differentiation, sentences 3-4 detail outputs and security, sentences 5-6 cover cost/auth, and sentence 7 provides an optimization tip. Logical progression from 'what' to 'how' to 'usage advice' makes it highly 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?

Given high complexity (formal verification, ZK proofs) and lack of output schema, the description effectively compensates by explaining return values (SAT/UNSAT, extracted values, cryptographic proof). It references the 'make_rules' prerequisite and cost structure. A minor gap is not mentioning the sibling 'verify_proof' for validating the returned ZK proof.

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%, establishing a baseline of 3. The description adds value by providing specific guidance on constructing the 'action' parameter ('end... with an explicit claim like I assert this complies with the policy for best extraction'), which aids the LLM in forming effective inputs beyond the schema's character limit constraint.

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

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

The description opens with a specific verb ('Enforce a guardrail: verify') and resource ('agent action against a compiled policy'), clearly defining scope. It distinguishes from siblings like 'quick_check' and 'check_logic' by emphasizing 'formal verification,' 'SMT solver,' and 'cryptographic ZK proof,' positioning this as the high-assurance option.

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

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

Provides explicit prerequisites ('Requires api_key,' 'Policy ID from make_rules'), cost constraints ('1 credit ($0.01)'), and a specific usage tip ('end the action with an explicit claim...'). It implicitly contrasts with alternatives by noting 'An SMT solver — not an LLM — determines,' guiding selection when formal guarantees are needed.

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

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

With no annotations, description carries full burden and successfully discloses cost ($0.10 USDC), blockchain (Base), authentication model (wallet required, no API key), and return format. Lacks explicit mention of idempotency or retry safety.

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

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

Two sentences with zero waste. Front-loaded with key differentiator ('Same formal verification as check_action, but...'), followed by auth requirements and return values. Every clause 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 2-parameter tool without output schema, the description comprehensively covers return values (SAT/UNSAT), side effects (payment), and auth context. Sufficient for correct invocation.

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

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

Input schema has 100% description coverage (action max chars, policy_id format), so baseline 3 is appropriate. Description adds no redundant parameter details but schema includes reference to sibling 'make_rules' for policy_id origin.

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 it performs 'formal verification' of actions (specific verb+resource), distinguishes from sibling 'check_action' by payment model (x402 vs credits), and specifies return values (SAT/UNSAT with ZK proof).

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 names sibling alternative 'check_action' and contrasts when to use each (pay-per-call vs credits). Also clarifies prerequisites: 'No API key or account needed — any agent with a wallet' can use this.

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

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

No annotations provided, but description carries burden well: discloses Z3 SAT solver mechanism, mathematical proof nature, and specific return values (CONSISTENT/CONTRADICTION/UNKNOWN). 'FREE — no account needed' implies stateless/safe operation, though could explicitly state 'read-only' or 'no side effects' for absolute clarity.

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?

Five sentences, each earning its place: 1) Core purpose, 2) Cost/account requirements, 3) Technical mechanism, 4) Methodology distinction, 5) Output contract. Front-loaded with action verb. Zero redundancy with schema fields.

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 no output schema, description explicitly documents return values and states. Explains input requirements (implied by 'quantitative claims'). Covers authentication model (none needed). Complete for a formal verification tool with simple 2-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 coverage is 100% so baseline is 3. Description adds value by explaining the nature of expected input ('quantitative and logical claims') and linking show_smt parameter to the underlying Z3 technology, helping users understand why they might enable it.

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

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

Specific verb 'Catch' + resource 'contradictions in reasoning' with clear scope. Distinguishes from siblings via 'FREE — no account needed' (vs check_action_paid) and 'formal verification, not an LLM second-guessing itself' (vs quick_check/check_action). Technical mechanism (Z3 SAT solver) clarifies methodology vs verify_proof.

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?

'Before acting on it' establishes timing. 'FREE — no account needed' removes barriers and implies cost advantage over paid siblings. 'Formal verification, not an LLM second-guessing' implies when to use vs heuristic alternatives. Lacks explicit 'when-not-to-use' or named alternative tools.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses cost behavior ('Free', 'No credits charged'), return value structure ('relevance score and which variables matched'), and the decision logic ('should_check'). It lacks explicit read-only/safety status or rate limits, but covers the critical behavioral aspects for a screening tool.

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

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

Every sentence earns its place: value proposition (free screen), output description (compensating for missing output schema), workflow logic (if-then-else), cost confirmation, and auth requirement. No redundancy or fluff; efficiently structured with clear logical flow.

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 lack of output schema, the description adequately describes return values (score, matched variables, should_check boolean). It establishes the relationship to sibling tools and explains the cost model. It could be improved by mentioning error conditions or rate limiting, but is sufficiently complete for tool selection.

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

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

Schema description coverage is 100%, so the baseline is 3. The description references 'policy variables' and 'action' in context but does not add syntax details, validation rules, or semantic meaning beyond what the schema already provides for the four parameters.

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

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

The description clearly defines the tool as a 'free relevance screen' that checks if an action touches policy variables before running a paid check. It uses specific verbs ('checks', 'screen') and clearly distinguishes itself from the paid 'check_action' sibling tool by emphasizing the cost-saving pre-screening function.

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

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

Provides explicit workflow guidance: 'If should_check is true, run check_action. If false... skip the paid check.' This clearly states when to use the tool (before paid checks), when to skip, and explicitly names the sibling tool to invoke next based on results.

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

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

No annotations provided, so description carries full burden. Discloses returns (API key + 325 credits), cost ($5.00), payment chain (Base), and critical warning 'Save the api_key — it is shown only once' about irretrievable credentials.

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?

Four sentences with zero waste: action/cost, returns, critical warning, and alternative—front-loaded with essential information and no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter creation tool, covers all critical aspects: purpose, payment mechanism, return values, irreversible side effects (API key visibility), and sibling differentiation.

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 has 100% description coverage for the username parameter. Description does not add param-specific semantics, but with full schema coverage, baseline 3 is appropriate as schema does the heavy lifting.

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?

Specific verb 'Create' + resource 'ICME Preflight account' + payment context 'x402 USDC payment ($5.00 on Base)' clearly distinguishes this from sibling create_account_card.

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 alternative: 'Use create_account_card instead if paying by credit card,' providing clear when-to-use guidance for crypto vs. credit card payment methods.

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

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

No annotations provided, so description carries full burden. Discloses cost ($5.00), payment processor (Stripe), return format (checkout_url), and session_id persistence for subsequent polling. Minor gap: doesn't mention failure modes (e.g., username conflicts) or 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?

Three sentences with zero waste: purpose+cost, immediate return+action, and subsequent workflow step. Information is front-loaded and logically sequenced.

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?

Without output schema, description adequately explains return values (checkout_url, implied session_id) and full workflow through API key retrieval. Could explicitly confirm that session_id is returned alongside checkout_url and mention error handling for 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?

Input schema has 100% description coverage ('Unique username...'), establishing baseline 3. Description adds no additional input parameter semantics, but appropriately compensates by describing output values (checkout_url, session_id) since no output schema exists.

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?

Specific verb 'Create' + resource 'ICME Preflight account' + method 'credit card ($5.00 via Stripe)' clearly distinguishes this from sibling 'create_account'. The scope and cost are explicitly stated.

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 describes the multi-step workflow: returns checkout_url → pay in browser → call 'poll_session' (naming the specific sibling tool) with session_id to retrieve API key. Clear sequencing 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?

With no annotations provided, the description carries the full burden. It successfully highlights the auth requirement ('Requires api_key') and describes the conceptual output (example actions that pass/fail). However, it omits safety characteristics (read-only status, idempotency) that agents need for mutation risk assessment.

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

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

Three well-structured sentences with logical flow: purpose, functionality/outcome, requirement. Front-loaded with the core action. 'Requires api_key' is slightly redundant with the required schema field but justified given the lack of annotations.

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?

Appropriately complete for a simple 2-parameter tool without output schema. Conceptually describes the return value (pass/fail examples). Minor gap in not addressing how this differs from 'run_tests', but sufficient for correct invocation given the schema.

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

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

Schema coverage is 100% with both parameters well-documented (policy_id references 'make_rules', api_key is described). The description adds minimal semantic value beyond the schema, only reinforcing the 'compiled policy' context and auth requirement, warranting the baseline score.

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

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

Clearly states the specific action (Review) and resource (auto-generated test scenarios for a compiled policy). Explains the value proposition (verify behavior before deploying). However, it does not explicitly differentiate from the sibling tool 'run_tests', which could cause selection ambiguity.

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?

Implies timing ('before deploying it') but lacks explicit when-to-use versus when-not-to-use guidance. Does not mention alternatives like 'run_tests' or 'check_action' for different validation needs.

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

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

With no annotations provided, the description carries full disclosure burden and succeeds well: it explicitly states the 300-credit cost, api_key authentication requirement, and return values (policy_id and test scenarios). It clarifies the compilation behavior (plain English → formal logic) and security properties ('jailbreak-proof'). Missing only failure modes or idempotency details.

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

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

Seven information-dense sentences with no redundancy. Front-loaded with the core transformation purpose ('Turn a plain-English policy into...'). Each subsequent sentence adds distinct value: input guidance, technical mechanism, approach contrast, return values, cost, and auth requirements. Slightly dense but efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite missing output schema and annotations, the description achieves completeness by explicitly documenting the return structure (policy_id and test scenarios), authentication requirements, and transaction costs. For a 2-parameter tool with moderate complexity, this compensates fully for missing structured metadata.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds value by specifying the writing style for the policy parameter ('the way you would explain them to a colleague'), which adds semantic guidance beyond the schema's syntax description. It reinforces the api_key source mentioned in the schema.

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

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

The description explicitly states the tool compiles plain-English policies into formal SMT-LIB logic for mathematical enforcement, distinguishing it from heuristic approaches. It clearly identifies the input (policy) and output (policy_id, test scenarios), with specific technical mechanism (solver-based proof vs LLM judging) that differentiates it from sibling checking/verification tools.

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

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

Provides implicit guidance through contrast ('No prompt engineering. No LLM judges'), indicating this tool is specifically for formal, mathematical guardrail creation rather than heuristic policy enforcement. Explicitly notes prerequisites ('Requires api_key', 'Costs 300 credits'), though it lacks explicit 'use X instead for Y' sibling comparisons.

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

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

No annotations provided, so description carries full burden. Discloses return state machine ('pending or complete') and conditional return value ('returns the api_key' on completion after signup). Lacks error handling or rate limit disclosure, but covers primary behavioral outcomes adequately.

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

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

Three sentences with zero waste: purpose declaration, return value specification, and usage guidance. Front-loaded with action verb. No redundant or filler content despite covering complex workflow state transitions.

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 single-parameter polling tool without output schema, description fully compensates by documenting return values (pending/complete/api_key) and workflow integration. Adequate complexity coverage given simple input structure.

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 has 100% description coverage ('session_id returned by create_account_card or top_up_card'), establishing baseline 3. Description references session_id in workflow context but does not add semantic meaning beyond schema documentation.

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 opens with specific verb ('Check') and resource ('status of a Stripe card payment'), clearly distinguishing from generic siblings like check_action or check_logic. Explicitly ties to Stripe card workflow, creating clear functional boundaries.

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 workflow prerequisites: 'Call this after create_account_card or top_up_card.' Provides clear temporal context ('once the user has paid') and distinguishes from account creation (create_account) or logic checking (check_logic) siblings by specifying payment polling use case.

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

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

With no annotations, description carries full burden and discloses: cost ('1 credit'), auth requirement ('Requires api_key'), response constraints ('returns only ALLOWED or BLOCKED with no proof details'), and implementation equivalence ('Same formal verification under the hood'). Deducting one point for missing error handling or failure modes.

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?

Four sentences, zero waste. Front-loaded with critical output format (ALLOWED/BLOCKED). Each sentence earns its place: purpose, usage context, technical equivalence, and operational requirements (cost/auth). No redundant or filler text.

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?

No output schema exists, so description appropriately explains return values ('ALLOWED or BLOCKED'). Covers authentication, cost, and underlying implementation for a complex formal verification tool. Complete for a 3-parameter tool, though could specify error response format.

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 has 100% description coverage (policy_id, action, api_key all documented), establishing baseline 3. Description mentions api_key requirement but adds no semantic details about parameter formats, validation rules, or relationships beyond what the schema already provides.

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?

States specific verb+resource ('guardrail verdict') and clearly distinguishes from siblings by contrasting 'minimal response' against 'full SAT/UNSAT report or ZK proof' (likely referring to check_action and verify_proof). Explicitly defines the binary output (ALLOWED/BLOCKED).

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

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

Explicit when-to-use ('lightweight gate') and when-not-to-use ('don't need the full SAT/UNSAT report or ZK proof'). Implicitly names alternatives by contrasting with full reports/proofs, giving clear selection criteria vs siblings.

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

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

With no annotations provided, the description carries the full burden and discloses the api_key authentication requirement. However, it lacks disclosure of side effects (whether test results are persisted, if the policy is modified, or what happens on test failures) that would be critical for a 'run' operation without readOnly/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?

Three sentences with zero waste: sentence 1 defines purpose, sentence 2 provides workflow timing, sentence 3 states auth requirements. Information is front-loaded with the primary action stated immediately.

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 2-parameter tool with simple types and no output schema, the description adequately covers purpose, prerequisites, and workflow position. Minor gap in not describing return values or test failure behavior, but acceptable given the limited complexity.

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

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

Schema coverage is 100%, so the schema fully documents both parameters ('Your ICME API key' and 'Policy ID to test'). The description mentions 'Requires api_key' which reinforces the authentication requirement, but adds no additional semantic context about parameter formats or validation rules 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 specific action (run saved test cases), target resource (policy), and expected validation outcome (confirm blocking/allowing behavior). It distinguishes from siblings like 'check_action' (implied single check) and 'make_rules' (creation vs. validation) by emphasizing the comprehensive test case execution.

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

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

Explicitly states the workflow sequence: 'Run this after make_rules and before using the policy in production.' This provides clear when-to-use guidance and positions the tool correctly in the policy lifecycle relative to the sibling 'make_rules' tool.

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

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

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: fixed denomination (500 credits), exact cost ($5.00), specific payment protocol (x402) and network (Base), plus authentication requirements. Minor gap in not describing idempotency or failure behaviors.

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

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

Three tightly constructed sentences with zero waste: action/amount/method in sentence one, sibling differentiation in sentence two, and prerequisites in sentence three. Information is appropriately 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?

For a simple single-parameter payment tool with no output schema, the description adequately covers the fixed-amount behavior, payment rail specifics, and authentication needs. Minor deduction for not describing return values or success/failure indicators given the absence of an output 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 coverage is 100% with the single 'api_key' parameter already documented as 'Your ICME API key'. The description confirms 'Requires api_key' but adds no additional semantic context (format, length, where to obtain it) 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?

Description states a specific verb ('Add'), exact resource ('500 credits'), precise method ('x402 USDC payment'), and cost ('$5.00 on Base'). It clearly distinguishes from sibling 'top_up_card' by specifying the crypto payment rail.

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 names the sibling alternative 'top_up_card' and states exactly when to use it instead ('for credit card payment with volume discounts'), providing clear selection criteria between the two topping methods.

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

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

No annotations provided, so description carries full burden. It discloses critical behavioral traits: returns 'checkout_url' (indicating redirect-based payment flow, not immediate execution), volume bonus calculations, and credit expiration policy ('never expire'). Missing idempotency or failure mode details.

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

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

Information-dense but highly efficient structure. Front-loaded with action and return type, followed by tier details (necessary for usage), persistence guarantee, and auth requirement. No redundant or filler text; every clause provides actionable 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?

Appropriate for a 2-parameter tool without output schema. Description covers: operation purpose, return value (checkout_url), valid input constraints (specific dollar tiers), side effects (credit addition), and authentication needs. Sufficient for correct invocation.

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

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

Schema has 100% description coverage, establishing baseline. Description adds significant semantic value by mapping each amount_usd tier to specific credit values and bonus percentages (e.g., '$100 = 12,000 (+20%)'), which helps agents understand the value proposition and validate inputs.

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?

Clear specific verb ('Add') + resource ('credits') + method ('via credit card') + value proposition ('volume bonuses'). The 'credit card' specificity distinguishes it from sibling tool 'top_up', implying this is the credit-card-specific variant.

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

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

Provides implicit context through 'via credit card' and notes prerequisites ('Requires api_key'). However, it lacks explicit guidance on when to choose this over sibling 'top_up' (e.g., payment method differences) or warnings about the checkout flow behavior.

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

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

No annotations provided, so description carries full burden. Richly discloses: cost model ('No additional cost'), latency ('under one second'), async timing ('Wait a few minutes'), authorization ('any third party or monitoring agent'), and idempotency ('Single-use per proof').

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?

Four sentences, zero waste. Front-loaded with core purpose, followed by performance characteristics, timing constraints, and usage limits. Every sentence delivers actionable 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?

Strong coverage of operational context (cost, latency, auth, timing) despite no output schema. Explains what confirmation entails ('guardrail check was performed correctly'). Minor gap: doesn't describe failure modes or return structure, though 'Confirms' implies boolean verification outcome.

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

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

Schema coverage is 100% with detailed proof_id description. Description adds critical semantic constraint that the proof is 'Single-use per proof,' indicating consumption behavior not captured in schema syntax. Baseline 3, elevated by usage 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?

States specific verb (verify) + resource (ZK proof) + scope (from prior check_action call). Explicitly distinguishes from sibling 'check_action' by contrasting with 're-running it' and referencing the prior call requirement.

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 defines when to use ('from a prior check_action call'), temporal prerequisite ('Wait a few minutes after the check'), and consumption constraint ('Single-use per proof'). Clear alternative path implied (re-running check_action vs verifying proof).

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