DevX Agent Hub

Verify an on-chain payment (tx confirmation)

verify_crypto_payment

Read-onlyIdempotent

Verify a crypto payment / transaction confirmation: given a tx hash on Base, Polygon, Arbitrum, Optimism or Ethereum returns status, confirmations, native value and decoded USDC transfers; with to and min_usdc it answers whether the recipient received at least that amount. $0.01 USDC on Base via x402. Price: $0.01. First call returns the x402 PaymentRequired (no charge); retry with payment in _meta["x402/payment"].

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tx": "<tx>"
    },
    "name": "verify_crypto_payment"
  }
}

Input Schema

Name	Required	Description	Default
`to`	No
`tx`	Yes
`chain`	No		base
`min_usdc`	No
`x402_payment`	No	Optional. Base64 x402 v2 PaymentPayload, for clients that cannot set params._meta["x402/payment"]. Omit on the first call to get the exact price.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: return fields, recipient/minimum-amount semantics, the $0.01 USDC cost on Base, the no-charge first call, and the retry mechanism via _meta["x402/payment"]. These details are essential for invoking a paid verification tool correctly.

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

Conciseness4/5

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

The description is front-loaded with purpose and return behavior, then transitions into payment mechanics. It is generally efficient, but repeats the price twice ('$0.01 USDC on Base via x402. Price: $0.01.') and could be trimmed slightly.

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

Completeness4/5

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

With no output schema, the description carries the burden of explaining returns, and it lists status, confirmations, native value, and decoded USDC transfers. It also explains the payment flow. It could do more on possible status values or error cases, but it is complete enough for an agent to call correctly.

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

Parameters4/5

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

Schema description coverage is only 20%, so the description must compensate. It meaningfully explains tx as a tx hash, chain options, and that to plus min_usdc answer whether the recipient received at least that amount; the x402 payment parameter is already described in the schema. It stops short of detailing formats or edge-case behavior for min_usdc and to beyond what the schema provides.

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

Purpose5/5

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

The description names a specific verb and resource: it verifies a crypto payment/transaction confirmation from a tx hash and returns status, confirmations, native value, and decoded USDC transfers. This clearly distinguishes it from sibling tools like create_crypto_payment_request, crypto_address_validate, and wallet_balances_multichain.

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

Usage Guidelines4/5

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

It gives clear usage context, including that passing to and min_usdc answers whether a recipient received at least that amount, and it explains the x402 payment flow: first call returns PaymentRequired with no charge, then retry with payment. It does not explicitly compare itself to sibling alternatives 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.

All DevX Agent Hub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?