What Is MCP and Why It Matters for Payments

The Model Context Protocol (MCP) is an open standard, originally proposed by Anthropic and now adopted across the AI tooling ecosystem, that defines how AI assistants connect to external tools, data sources, and APIs. Think of it as the USB-C of AI integrations: instead of every IDE and chat client building bespoke plugin systems, MCP gives all of them a shared way to discover and call tools.

For payments, this matters more than it sounds. Before MCP, giving an agent the ability to send money meant either (a) hard-coding API calls into the agent's prompts and praying it formed the request correctly, or (b) building a custom plugin for every client you wanted to support. MCP collapses that complexity into one server that any compliant client can consume.

The deeper benefit is structure. An MCP tool has a typed schema. When the agent calls send_payment, it must pass a to address and an amount_usdc number, and nothing else. There is no room for the agent to hallucinate a strange parameter or skip a required field, because the protocol validates the call before it ever reaches the payment server. That structure is what makes MCP-based AI agent payments safer than ad-hoc HTTP calls.

The Five MoltPe MCP Tools

The MoltPe MCP server exposes five tools. Each is callable directly from the agent's conversation, with the same authentication and policy enforcement that REST API users get.

send_payment

Sends USDC from the agent's wallet to a recipient address. Parameters: to (string, EVM address), amount_usdc (number), memo (optional string for audit trail). Returns the transaction hash and the post-transaction balance.

{
  "to": "0xRecipientAddress...",
  "amount_usdc": 0.50,
  "memo": "API access for paper-search"
}

The server validates against per-transaction caps and daily limits before signing. A request that violates policy returns an error with the specific limit that was hit; no funds move and no on-chain transaction is created.

check_balance

Returns the wallet's current USDC balance, daily-limit headroom remaining, and any pending transactions. No parameters required. This is the tool agents call most frequently because it is cheap and lets them decide whether they can afford an upcoming payment.

list_transactions

Returns the recent transaction history for the wallet. Optional parameters: limit (default 20), since (ISO timestamp), status (one of completed, blocked, pending). Useful when an agent needs to confirm a previous payment landed before triggering downstream work.

agent_info

Returns metadata about the wallet itself: chain, address, name, and current spending policies. This lets the agent introspect its own constraints. A well-designed agent will call agent_info at the start of a session to learn its limits and plan its work accordingly.

call_x402_endpoint

The most powerful tool in the set. The agent passes a URL; the MCP server fetches it. If the endpoint returns 402 Payment Required, the server pays the fee from the agent's wallet (subject to spending policies) and retries the request. The agent receives the final response body in a single tool call, with no awareness of the underlying payment handshake.

{
  "url": "https://api.example.com/research-paper/12345"
}

This makes it trivial to give an agent access to the growing world of x402 paid APIs. The full request flow is documented in the x402 protocol complete guide.

Installing the MCP Server

Setup takes about three minutes. Install the server, add a config block, restart your client.

Claude Desktop

Edit the Claude Desktop config file (location varies by OS, the dashboard shows yours under MCP Setup) and add:

{
  "mcpServers": {
    "moltpe": {
      "command": "npx",
      "args": ["-y", "@moltpe/mcp-server"],
      "env": {
        "MOLTPE_API_KEY": "your-api-key-here"
      }
    }
  }
}

Restart Claude Desktop. The five MoltPe tools appear in the tool palette and are now callable from any conversation.

Cursor and Windsurf

Both clients use the same config schema. Add the same block to their respective MCP config files, restart, and the tools become available inside agent mode.

Custom Clients

Any client built with the official MCP SDK can launch the MoltPe server. Point it at npx -y @moltpe/mcp-server with the API key in the environment, and the standard MCP discovery flow will pick up all five tools automatically.

Example Agent Flows

Two flows that illustrate how MCP payment tools change what an agent can do without human handholding.

Flow 1: Research Agent Buying Paper Access

The user asks: "Find me three recent papers on graph neural networks and summarize them."

  1. Agent searches Google Scholar (free, no payment).
  2. Agent identifies three relevant papers behind paywalls.
  3. For each paper, the agent calls call_x402_endpoint with the publisher's API URL. The MoltPe server pays the access fee (typically $0.10 to $1.00) and returns the full text.
  4. Agent summarizes each paper and replies to the user.

Total agent-side payment code: zero. The MCP layer handles authentication, payment, retries, and audit trail.

Flow 2: Customer-Service Agent Issuing a Refund

A support agent decides a customer is owed a $5 refund. It calls:

send_payment({
  "to": customer_wallet,
  "amount_usdc": 5.00,
  "memo": "refund: ticket #4821"
})

The MoltPe policy engine confirms the per-transaction cap is at least $5, the daily limit has room, and the wallet balance is sufficient. The transaction settles in under a second and the memo lands in the audit trail tied to ticket #4821 forever. If any check fails, the agent gets back a structured error and can either escalate to a human or queue the refund for tomorrow.

How Policy Enforcement Works

The most important architectural fact about MCP payment tools is that policy enforcement does not live in the MCP server. It lives one layer down, in the MoltPe core service. The MCP server is essentially a translation layer: it takes a tool call from the client and forwards it as a signed REST request to MoltPe's API.

That means even a malicious or compromised MCP client cannot bypass spending limits. The client sees the same outcome a direct API caller would see: the request goes to MoltPe, MoltPe checks all four policy gates (balance, per-transaction cap, daily limit, signature), and either signs the transaction or returns a denial. The agent's prompt has no path to override the policy engine.

This is by design. If we put policy enforcement in the MCP server, an attacker who compromised the client (via prompt injection, for example) could potentially manipulate the server too. By keeping enforcement remote and signature-verified, the policy boundary stays intact even when everything closer to the agent is fully compromised. The detailed mechanics are covered in our spending policies guide.