SendCheck — EVM address verification (x402)

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the paid nature, the exact cost and payment method, the two-phase protocol, authentication via payment, and the nature of the returned verdict. This goes well beyond the schema and provides meaningful behavioral transparency.

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

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

The description is dense but every sentence contributes useful information: purpose, cost/auth model, checks performed, two-phase workflow, and authentication model. It is structured logically and front-loads the core purpose before procedural 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?

For a complex paid two-phase tool with no output schema, the description is largely complete: it explains the workflow, the payment requirement, what is checked, and what the report contains. It falls slightly short of a 5 because it does not describe exact output fields, error conditions, or behavior on invalid input, but the essential calling context is covered.

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 baseline is 3, but the description adds real semantic value beyond the schema. It explains the two-phase significance of x_payment, clarifies that the first call must omit it, and describes the payment challenge flow that gives meaning to the parameter.

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 operation: paid pre-send verification of one EVM address on one chain, with specific checks like checksum, wallet-vs-contract, balances, and a verdict. It is specific and resource-focused, but it does not explicitly distinguish itself from sibling tools such as validate_address or deep_scan.

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 operational context: when to call without x_payment first, how to obtain the payment challenge, and when to call again with the X-Payment header. It does not, however, state when to choose this tool over siblings or list exclusion conditions.

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

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

With no annotations, the description carries the full burden and it does well: it discloses that the tool is paid ($0.05 USDC via x402), requires EIP-3009 on Base, follows a two-phase challenge/response flow, and that the first call returns a payment challenge while the second requires x_payment and returns the report. This explains the interaction model and cost, which is crucial for an agent to invoke it correctly.

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 dense sentences that front-load the key facts: paid status, scope, cost, and two-phase behavior. No filler; every clause adds a decision-relevant detail (chains, flags, payment mechanism, call sequence). The structure is clear despite the parenthetical cost detail.

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 paid, two-phase tool with no output schema and no annotations, the description is largely complete: it covers the payment prerequisite, the call sequence, and the expected report. However, it does not describe the report's structure or fields, nor error/failure behavior if payment is not provided, which an agent might need for robust handling.

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 baseline is 3. The description adds workflow context: it explains that x_payment is only used in the second call and ties it to the payment challenge from the first call, and it specifies the payment channel (x402, EIP-3009 on Base). This clarifies the parameter's role beyond the schema's string description.

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 a specific verb and resource: 'deep scan' for an address, with clear scope: 'full verification across ALL FIVE chains (Base, Ethereum, Arbitrum, Optimism, Polygon)' and specific detection features ('wrong-network detection and USDC/USDT token-mismatch flags'). The 'TWO-PHASE like check_address' phrase anchors it relative to siblings without confusing it with them, because the multi-chain and paid attributes distinguish it.

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

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

The description implies the use case: when the user needs comprehensive multi-chain verification and accepts the $0.05 USDC cost. It explicitly describes the two-phase protocol so an agent knows to call twice, but it does not state when to choose check_address or validate_address instead, nor when not to use this paid 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, the description carries the burden and does well: it discloses that the operation is free and read-only, specifies exactly what is verified (EIP-55 checksum), lists failure modes it catches (typos, dropped characters, clipboard malware), and openly warns about its limitation. It does not mention return values, but that is a minor gap for a check-like 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?

Two sentences with no filler. The first sentence front-loads the purpose, cost, and key value; the second adds the critical limitation and usage ordering. Every clause carries 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?

For a single-parameter tool with no output schema, the description covers what it does, what it catches, its limitation, and when to use it in the workflow. The only omission is the exact return format, which is not essential for such a simple validation 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?

The schema already fully documents the address format (0x + 40 hex characters, any casing). The description adds meaning by explaining the EIP-55 checksum verification behavior, which tells the agent what will be done with the address beyond its format. It also clarifies that casing is relevant to the checksum check.

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

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

The description clearly states a specific verb and resource: a free pre-send EIP-55 checksum check of an EVM address. It explicitly positions itself relative to check_address ('Run this before paying for check_address'), distinguishing it from that sibling, and its 'pre-send check' framing separates it from deep_scan's implied deeper analysis.

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

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

It explicitly instructs when to use the tool: run before paying for check_address. It also provides a when-not-to-rely-on-it statement by noting that a passing checksum is not payee verification. However, it gives no guidance about deep_scan, leaving some ambiguity about when to choose this over that sibling.

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