Skip to main content
Glama
CryptoAPIs-io

CryptoAPIs x402 Pay MCP

Official
by CryptoAPIs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

x402_pay_tool

Call a tool on another MCP server, handle x402 payment requirements with local signing, and return the paid result.

Instructions

Call a TOOL on another MCP server and, if that tool requires payment, pay it automatically with x402 and return the paid result. This is the MCP-transport twin of x402_pay: use x402_pay for an HTTP url, and THIS for a paid tool on another MCP server. On a challenge it reads the PaymentRequired (from structuredContent, falling back to content[0].text), authorizes via the CryptoAPIs buyer /authorize, signs LOCALLY (non-custodial — the key never leaves this process), and retries the tool call once with the payment in _meta["x402/payment"] (a raw object, no base64 — MCP carries structured JSON natively). Returns { paid, result, settlement? }; the settlement receipt comes back in _meta["x402/payment-response"]. The upstream server is launched over stdio for the call and shut down afterwards. Same credentials and keys as x402_pay: CRYPTOAPIS_API_KEY + X402_WALLET_ID, plus X402_PRIVATE_KEY (EVM) / X402_SVM_SECRET (Solana). Supported today: EVM (eip712) and Solana; Tron, UTXO, Kaspa and XRP return a clear coming-soon result. Use allowedNetworks and maxAmount as guardrails. SECURITY: this tool holds spending keys and launches the process you name — use only in trusted local environments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
serverYesThe upstream MCP server to call, launched over stdio. It is started for this call and shut down afterwards.
tronKeyNoTron private key (hex). Falls back to X402_TRON_KEY, then to privateKey/X402_PRIVATE_KEY.
utxoWifNoUTXO private key in WIF format. Falls back to X402_UTXO_WIF.
xrpSeedNoXRP secret/seed. Falls back to X402_XRP_SEED.
kaspaKeyNoKaspa private key (hex). Falls back to X402_KASPA_KEY.
toolNameYesThe name of the tool to call on that server
walletIdNoThe CryptoAPIs buyer-service wallet RECORD ID (from POST /wallets) — NOT the on-chain address. Falls back to the X402_WALLET_ID env var.
argumentsNoArguments to pass to that tool
maxAmountNoSafety cap: refuse to pay if the required atomic-unit amount exceeds this
svmSecretNoSolana secret key, base58-encoded — signs svm-transaction payments. Falls back to X402_SVM_SECRET.
privateKeyNoEVM private key (hex, 0x optional) — signs the eip712 payment, and Tron by default. Falls back to X402_PRIVATE_KEY. SECURITY: trusted local environments only.
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. Addedv0.5.3

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it does: it discloses the challenge/retry flow, non-custodial local signing ('the key never leaves this process'), where PaymentRequired is read from (structuredContent with content[0].text fallback), that the upstream server is launched over stdio and shut down per call, supported vs coming-soon chains, and an explicit 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?

Dense but every sentence earns its place — flow, return shape, credentials, supported chains, and security are all load-bearing for a 14-parameter tool. Slightly over-packed with parentheticals, but front-loaded and non-redundant.

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?

With no output schema present, the description supplies the return contract ('{ paid, result, settlement? }') and where the settlement receipt arrives (_meta['x402/payment-response']), plus credential and network coverage. Given the tool's complexity and nested server object, an agent has everything needed to call it 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 coverage is 100%, so the baseline is 3 and the schema already documents fallbacks and formats. The description adds meaning on top by naming the credential set (CRYPTOAPIS_API_KEY, X402_WALLET_ID, X402_PRIVATE_KEY/X402_SVM_SECRET) and framing allowedNetworks/maxAmount as guardrails, which tells the agent how to use them defensively.

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+resource ('call a tool on another MCP server and pay it automatically with x402') and explicitly positions itself against the sibling x402_pay ('MCP-transport twin... use x402_pay for an HTTP url, and THIS for a paid tool on another MCP server'). An agent can unambiguously separate it from x402_pay and x402_discover.

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?

Gives an explicit selection rule against the closest alternative and a clear exclusion ('use x402_pay for an HTTP url'), plus a security scoping condition ('use only in trusted local environments'). Nothing about when-to-use is left to inference.

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