Skip to main content
Glama
CryptoAPIs-io

CryptoAPIs x402 Pay MCP

Official

x402_pay

Fetch HTTP URLs that respond with 402 Payment Required, authorize via CryptoAPIs, sign x402 payments locally, and return the paid response.

Instructions

Fetch an HTTP resource and, if it returns 402 Payment Required, pay it automatically with x402 and return the paid response. On a 402 it: parses the merchant's price, authorizes via the CryptoAPIs buyer /authorize, signs the payment LOCALLY (non-custodial — the key never leaves this process), and retries with the X-PAYMENT header. Returns { status, paid, body, settlement? }. This is for HTTP URLs — to pay a paid MCP TOOL on another server, use x402_pay_tool instead. Supported today: EVM (eip712, e.g. Base USDC) and Solana. Tron, UTXO (bitcoin/ltc/doge/dash/bch/zcash), Kaspa and XRP are UPCOMING — wired but not yet enabled, and paying on them returns a clear coming-soon (family_not_yet_supported) result. Set CRYPTOAPIS_API_KEY + X402_WALLET_ID once, plus the signing key(s) for the chain(s) you pay on: X402_PRIVATE_KEY (EVM hex), X402_SVM_SECRET (base58). A scheme with no configured key errors cleanly (never mis-signs). Env vars keep keys OUT of tool-call logs. Use allowedNetworks to restrict chains, maxAmount as a per-call spend cap, and allowedHosts to restrict WHICH SITES may be paid (a url outside the list is refused before any network call; set X402_ALLOWED_HOSTS in the MCP config to pin it outside the model's reach). SECURITY: this tool holds spending keys — use only in trusted local environments, and prefer pinning allowedHosts + maxAmount via env for unattended runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe (possibly paywalled) resource URL to fetch
bodyNoRequest body (string; set content-type via headers if needed)
apiKeyNoYour CryptoAPIs API key with the X402_BUYER feature (used only to call the buyer /authorize). Falls back to the CRYPTOAPIS_API_KEY env var — set it once and omit this.
methodNoHTTP method (default GET)
headersNoExtra request headers
tronKeyNoTron private key (hex). Falls back to X402_TRON_KEY, then to privateKey/X402_PRIVATE_KEY (same secp256k1 curve).
utxoWifNoUTXO private key in WIF format — signs utxo-transaction payments (bitcoin/ltc/doge/dash/bch/zcash). Falls back to X402_UTXO_WIF.
xrpSeedNoXRP secret/seed (base58, e.g. s...) — signs xrp-transaction payments. Falls back to X402_XRP_SEED.
kaspaKeyNoKaspa private key (hex, 32 bytes) — signs kaspa-transaction payments. Falls back to X402_KASPA_KEY.
walletIdNoThe CryptoAPIs buyer-service wallet RECORD ID (the id returned by POST /wallets) — NOT the on-chain address; passing an address returns wallet_not_found. Falls back to the X402_WALLET_ID env var. Create one first (once per blockchain+network): POST https://ai.cryptoapis.io/x402/buyer/wallets with {blockchain, network (CAIP-2 id like eip155:8453 or solana:<genesisHash> — NOT a bare name), address (your public address; required for Solana/Kaspa)} → returns walletId.
maxAmountNoOptional safety cap: refuse to pay if the required atomic-unit amount exceeds this
svmSecretNoSolana secret key, base58-encoded (64-byte keypair secret) — signs svm-transaction payments. Falls back to X402_SVM_SECRET.
privateKeyNoEVM private key (hex, 0x optional) — signs the eip712 (EVM) payment, and Tron by default. Falls back to X402_PRIVATE_KEY. SECURITY: trusted local environments only.
allowedHostsNoRestrict WHICH HOSTS may be paid, e.g. ["api.acme.com"] (a leading dot matches subdomains: ".acme.com"). A url outside the list is refused BEFORE any network call. Falls back to the X402_ALLOWED_HOSTS env var (comma-separated) — set it there to pin the allowlist OUTSIDE the model's reach, so a prompt-injected url cannot widen it.
buyerBaseUrlNoOverride the buyer service base URL (default https://ai.cryptoapis.io/x402/buyer)
allowedNetworksNoRestrict which CAIP-2 networks to pay on (e.g. ["eip155:8453"])

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it details the 402 sequence (parse price, authorize, sign locally non-custodially, retry with X-PAYMENT), the return shape {status, paid, body, settlement?}, supported vs upcoming chains, the exact behavior on unsupported families (family_not_yet_supported), clean error handling for unconfigured keys, and a security warning about holding spending keys.

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?

Purpose and 402 behavior are strongly front-loaded, followed by alternatives, chain support, config, and security in a logical order. It is long for a description, and the SECURITY warnings and env-var reiterations appear twice, so a small amount of trimming is possible.

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

Completeness5/5

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

Despite 16 parameters, no output schema, and no annotations, the description covers what an agent needs: the return shape, the payment flow, supported/upcoming networks, error semantics, required configuration, and safety controls. Nothing material for correct invocation is missing.

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 100%, so the baseline is 3. The description goes beyond the schema by framing allowedNetworks, maxAmount, and allowedHosts as a coherent safety posture, explaining that env-pinning keeps the allowlist outside the model's reach, and describing the CRYPTOAPIS_API_KEY/X402_WALLET_ID setup once. This adds genuine framing value, though much of the per-parameter detail is already in the schema.

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?

States a specific verb (fetch) and resource (HTTP resource), then specifies the conditional behavior (pay on 402 and return the paid response). It explicitly distinguishes itself from the sibling x402_pay_tool (HTTP URLs vs paid MCP tools), so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Explicitly names the alternative (x402_pay_tool for paid MCP tools on another server) and the condition that selects it. It also gives when-to-use guidance for the safety controls (allowedNetworks, maxAmount, allowedHosts) and the trusted-local-environment precondition for holding spending keys.

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

Deploy Server

Other Tools