Skip to main content
Glama

pay_x402

Fetches a URL, handles HTTP 402 payment requirements by signing an EIP-3009 or Permit2 authorization, then retries the request and returns the response with its settlement receipt.

Instructions

Handle an x402 payment flow. Fetches a URL, and if the server returns HTTP 402 Payment Required, parses the payment requirements (v1 body or v2 PAYMENT-REQUIRED header), signs an EIP-3009 TransferWithAuthorization for the "exact" scheme (no gas, nothing broadcast by the payer), and retries the request with the payment header. AgentWallet paywalls are paid by on-chain transfer instead. The "upto" scheme is settled with a Permit2 authorization bounded by the cap. Returns the final response and the settlement receipt. Supports the x402 open payment standard (https://x402.org). max_payment can only lower the operator's cap for one call.

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": {
      "url": "<url>",
      "wallet_id": "<wallet_id>"
    },
    "name": "pay_x402"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL to access (will handle 402 payment if required)
bodyNoOptional request body for POST/PUT requests
methodNoHTTP method (GET, POST, PUT, DELETE)GET
headersNoOptional JSON string of additional request headers. Credentials placed here (Authorization, Cookie, API keys) are sent only to the origin in `url`; if the endpoint redirects to a different origin they are dropped, not forwarded.
wallet_idYesWallet ID to pay from
approval_idNoAn approval id from an earlier over-cap attempt. Once the owner has approved it, pass it here to make that one payment.
max_paymentNoMaximum payment in human-readable format (e.g. "1.00" for 1 USDC). Lowers the operator's AGENTWALLET_MAX_AUTOPAY ceiling (default "1") for this one call; it can never raise it, and a value above the ceiling is ignored and reported as max_payment_ignored.
prefer_chainNoPreferred chain ID if the server accepts payment on multiple chains (e.g. 8453 for Base, 1 for Ethereum)
request_approvalNoHosted wallets only. When the payment exceeds the cap, email the wallet owner an approve/deny link instead of refusing, and return an approval_id to retry with. Default true unless AGENTWALLET_APPROVALS=0.
fresh_authorizationNoSign a new authorization even if one for the same endpoint, amount and recipient is still valid. By default a repeat call within the validity window re-sends the earlier signature (same nonce, so it cannot settle twice) instead of paying again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.14.8
    • addedInput schema / properties / prefer_chain / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / prefer_chain / minimum
      Added value: +-9007199254740991
    • addedInput schema / properties / wallet_id / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / wallet_id / minimum
      Added value: +-9007199254740991
  2. Changed5 schema fields changedv1.14.2
    • addedInput schema / properties / approval_id
      Added value: +{
      +  "description": "An approval id from an earlier over-cap attempt. Once the owner has approved it, pass it here to make that one payment.",
      +  "type": "string"
      +}
    • addedInput schema / properties / fresh_authorization
      Added value: +{
      +  "description": "Sign a new authorization even if one for the same endpoint, amount and recipient is still valid. By default a repeat call within the validity window re-sends the earlier signature (same nonce, so it cannot settle twice) instead of paying again.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / headers / description
      Previous value: -"Optional JSON string of additional request headers"New value: +"Optional JSON string of additional request headers. Credentials placed here (Authorization, Cookie, API keys) are sent only to the origin in `url`; if the endpoint redirects to a different origin they are dropped, not forwarded."
    • changedInput schema / properties / max_payment / description
      Previous value: -"Maximum payment in human-readable format (e.g. \"1.00\" for 1 USDC). Rejects payments above this amount. Strongly recommended to prevent overspending."New value: +"Maximum payment in human-readable format (e.g. \"1.00\" for 1 USDC). Lowers the operator's AGENTWALLET_MAX_AUTOPAY ceiling (default \"1\") for this one call; it can never raise it, and a value above the ceiling is ignored and reported as max_payment_ignored."
    • addedInput schema / properties / request_approval
      Added value: +{
      +  "description": "Hosted wallets only. When the payment exceeds the cap, email the wallet owner an approve/deny link instead of refusing, and return an approval_id to retry with. Default true unless AGENTWALLET_APPROVALS=0.",
      +  "type": "boolean"
      +}
  3. First observedv1.7.3

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden well: it discloses that the payer signs an EIP-3009 TransferWithAuthorization, no gas is paid and nothing is broadcast by the payer, AgentWallet paywalls use an on-chain transfer, the upto scheme uses Permit2 bounded by the cap, and it returns the settlement receipt. It does not state whether payments are irreversible, what happens if settlement fails after signing, or whether there are spending-policy prerequisites, leaving some behavioral gaps.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then proceeds through the 402 branch, signing, retry, special paywall handling, settlement, and the max_payment constraint. Every sentence carries specific operational information, and the standard reference at the end is brief and useful rather than filler.

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?

For a 10-parameter payment tool with no annotations and no output schema, the description covers the full payment flow, return value (final response plus settlement receipt), approval mechanics, and cap behavior. It is still missing failure semantics and any prerequisite about wallet funding or spend policy, so it is strong but not complete.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already documents every parameter, including the cap-lowering behavior of max_payment, approval_id reuse, and fresh_authorization nonce reuse. The description adds only marginal meaning, mainly tying the upto scheme to the Permit2 cap, so the baseline of 3 is appropriate.

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

Purpose4/5

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

The description gives a specific verb and resource: it fetches a URL, detects HTTP 402, signs an EIP-3009 authorization, and retries with payment. This is much more concrete than a tautology and clearly differs in spirit from quote_x402, but it never names that sibling, so differentiation is implicit rather than explicit.

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 establishes clear context for use (any URL that may require x402 payment) and describes the over-cap approval path, but it does not explicitly say when to use this instead of quote_x402, simulate_transaction, or discover_x402. There are no stated exclusions or prerequisites such as wallet funding.

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