Skip to main content
Glama
clawallex

Clawallex MCP Server

by clawallex

clawallex_pay

Process payments using USDC by generating virtual cards for online checkouts, with options for wallet-based or on-chain self-custody transactions.

Instructions

Pay for a product or service using USDC. Creates a single-use flash virtual card (card_type=100), deducts from wallet balance, returns card details for checkout.

Mode A (mode_code=100, default): wallet balance → flash card. Immediate settlement. Mode B (mode_code=200): for callers with self-custody wallets — signing is performed by the caller. x402 on-chain two-stage flow: Stage 1 (Quote): POST with mode_code=200, chain_code, token_code. The 402 response is EXPECTED — it is a quote, NOT an error. Returns: card_order_id, client_request_id, x402_reference_id, payee_address, asset_address, final_card_amount, issue_fee_amount, fx_fee_amount, fee_amount, payable_amount. Agent signs: construct and sign an EIP-3009 transferWithAuthorization using your own wallet/signing library. Stage 2 requires the resulting signature and your wallet address (authorization.from). authorization fields: from=your wallet address, to=payee_address, value=maxAmountRequired, validAfter/validBefore=unix seconds validity window, nonce=random 32-byte hex (unique per auth). Stage 2 (Settle): POST again with SAME client_request_id + signed x402 data: - payment_requirements.payTo MUST equal payee_address from Stage 1 - payment_requirements.asset MUST equal asset_address from Stage 1 - payment_requirements.maxAmountRequired MUST equal payable_amount × 10^decimals (USDC = 6 decimals, e.g. '207.59' → '207590000') - payment_requirements.extra.referenceId MUST equal x402_reference_id from Stage 1 - extra.card_amount MUST equal amount, extra.paid_amount MUST equal amount + fee_amount - If settle is rejected, order stays pending_payment — fix params and retry with same client_request_id.

Fee structure: fee_amount = issue_fee_amount + fx_fee_amount. total_amount = amount + fee_amount.

Example (Mode A): clawallex_pay({ amount: 50, description: 'OpenAI API credits' })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesCard face amount in USD
descriptionYesWhat this payment is for
mode_codeNo100=wallet (default), 200=x402 on-chain
tx_limitNoPer-transaction limit in USD (optional, default 100.0000)
allowed_mccNoMCC whitelist, comma-separated (optional, e.g. '5734,5815')
blocked_mccNoMCC blacklist, comma-separated (optional, e.g. '7995')
client_request_idNoUUID idempotency key (<=64 chars). Mode B Stage 2: MUST reuse from Stage 1.
chain_codeNoChain code for Mode B Stage 1 (e.g. 'ETH')
token_codeNoToken code for Mode B Stage 1 (e.g. 'USDC')
extraNoMode B Stage 2 (required): { card_amount, paid_amount }
x402_reference_idNox402 reference ID. Card creation Stage 1: optional (server generates if omitted). Stage 2: use value from 402 response. Refill Mode B: required, serves as idempotency key.
x402_versionNox402 version (Mode B Stage 2, required)
payment_payloadNox402 payment payload (Mode B Stage 2, required)
payment_requirementsNox402 payment requirements (Mode B Stage 2, required)
payer_addressNoPayer wallet address (optional, final value from verify)

Implementation Reference

  • The handler for the 'clawallex_pay' tool, which processes payments and card creation requests, including Mode A (wallet) and Mode B (x402) flows.
      async (params) => {
        try {
          const modeCode = params.mode_code ?? 100;
          if (modeCode === 200) {
            const hasX402 = params.x402_version !== undefined || params.payment_payload !== undefined || params.payment_requirements !== undefined;
            if (hasX402) {
              const missing: string[] = [];
              if (params.x402_version === undefined) missing.push("x402_version");
              if (params.payment_payload === undefined) missing.push("payment_payload");
              if (params.payment_requirements === undefined) missing.push("payment_requirements");
              if (params.extra === undefined) missing.push("extra (must include card_amount and paid_amount)");
              if (missing.length > 0) {
                return { content: [{ type: "text" as const, text: `Mode B Stage 2 missing required fields: ${missing.join(", ")}.` }], isError: true as const };
              }
            } else {
              if (!params.chain_code || !params.token_code) {
                return { content: [{ type: "text" as const, text: "Mode B Stage 1 requires chain_code and token_code." }], isError: true as const };
              }
            }
          }
    
          const body: Record<string, unknown> = {
            mode_code: modeCode,
            card_type: 100,
            amount: params.amount.toFixed(4),
            client_request_id: params.client_request_id ?? randomUUID(),
          };
          if (params.tx_limit) body.tx_limit = params.tx_limit;
          if (params.allowed_mcc) body.allowed_mcc = params.allowed_mcc;
          if (params.blocked_mcc) body.blocked_mcc = params.blocked_mcc;
          if (params.chain_code) body.chain_code = params.chain_code;
          if (params.token_code) body.token_code = params.token_code;
          if (params.x402_reference_id !== undefined) body.x402_reference_id = params.x402_reference_id;
          if (params.x402_version !== undefined) body.x402_version = params.x402_version;
          if (params.payment_payload !== undefined) body.payment_payload = params.payment_payload;
          if (params.payment_requirements !== undefined) body.payment_requirements = params.payment_requirements;
          if (params.extra !== undefined) body.extra = params.extra;
          if (params.payer_address !== undefined) body.payer_address = params.payer_address;
    
          const result = await client.post<unknown>("/payment/card-orders", body);
          return toolOk({
            ...(result as Record<string, unknown>),
            _hint: `Card created for: ${params.description}. Use get_card_details to retrieve card number for checkout.`,
          });
        } catch (err) {
          if (err instanceof ClawallexApiError && err.statusCode === 402 && err.details) {
            return formatX402Quote(err.details as Record<string, unknown>);
          }
          return toolError(err);
        }
      },
    );
  • Zod schema definition for the inputs to the 'clawallex_pay' tool.
    {
      amount: z.number().describe("Card face amount in USD"),
      description: z.string().describe("What this payment is for"),
      mode_code: z.number().int().describe("100=wallet (default), 200=x402 on-chain").optional(),
      tx_limit: z.string().describe("Per-transaction limit in USD (optional, default 100.0000)").optional(),
      allowed_mcc: z.string().describe("MCC whitelist, comma-separated (optional, e.g. '5734,5815')").optional(),
      blocked_mcc: z.string().describe("MCC blacklist, comma-separated (optional, e.g. '7995')").optional(),
      client_request_id: z.string().max(64).describe("UUID idempotency key (<=64 chars). Mode B Stage 2: MUST reuse from Stage 1.").optional(),
      chain_code: z.string().describe("Chain code for Mode B Stage 1 (e.g. 'ETH')").optional(),
      token_code: z.string().describe("Token code for Mode B Stage 1 (e.g. 'USDC')").optional(),
      extra: z.record(z.unknown()).describe("Mode B Stage 2 (required): { card_amount, paid_amount }").optional(),
      ...x402Fields,
    },
  • Registration of the 'clawallex_pay' tool in the McpServer.
    server.tool(
      "clawallex_pay",
Behavior5/5

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

With no annotations provided, the description carries full behavioral disclosure. It explains the fee structure (issue_fee_amount + fx_fee_amount), state management (order stays pending_payment if settle rejected), cryptographic requirements (EIP-3009 transferWithAuthorization), and precise decimal handling (USDC = 6 decimals). It also clarifies the mutating nature (deducts from wallet, creates card).

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?

Despite substantial length, the description is well-structured with clear sections (Mode A, Mode B Stage 1/2, Fee structure, Example) and front-loaded purpose. Every paragraph serves a necessary function given the complexity of the x402 cryptographic flow. Minor deduction for density, but appropriate for a 15-parameter tool with two distinct operational modes.

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?

For a complex payment tool with 15 parameters, nested objects, no annotations, and no output schema, the description is remarkably complete. It covers return values for both modes (card details for Mode A, specific field list for Stage 1), error handling semantics, idempotency strategies, and cryptographic signing requirements—leaving no critical gaps in agent understanding.

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?

While the schema has 100% description coverage (baseline 3), the description adds significant semantic value by explaining cross-parameter relationships: how Stage 1 outputs (payee_address, asset_address, x402_reference_id) map to Stage 2 inputs (payment_requirements fields), the calculation logic for maxAmountRequired (payable_amount × 10^decimals), and idempotency constraints across stages.

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 opens with a clear action ('Pay for a product or service using USDC') and specifies the resource created ('single-use flash virtual card'). It distinguishes itself from sibling tools like 'clawallex_refill' or 'create_card_order' by emphasizing the flash card nature and the two distinct payment modes (wallet vs. x402 on-chain).

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 delineates Mode A (mode_code=100, default for wallet balance) versus Mode B (mode_code=200 for self-custody wallets with signing). Details the two-stage x402 flow (Quote vs. Settle), clarifies that 402 responses are expected quotes not errors, and specifies idempotency requirements using client_request_id. Provides concrete usage example for Mode A.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clawallex/clawallex-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server