A Quick Primer on MCP

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, for giving large language models access to tools, data, and actions in the outside world. Before MCP, every LLM host (Claude Desktop, Cursor, Windsurf, custom agent frameworks) required its own proprietary plugin format. MCP unifies this: write a tool server once, and any MCP-compatible client can use it. You can read the official specification in the Anthropic MCP docs.

MCP matters enormously for payments. An LLM that can only generate text cannot transact. An LLM that can call tools can. When you hand an agent a send_payment tool, you have crossed the line from chatbot to autonomous economic actor. The agent can now pay for API calls, settle invoices, rebalance wallets, or compensate other agents for services — all inside the normal chat loop.

The MoltPe MCP server fits directly into this model. It runs as a local stdio process alongside your MCP client, exposes a small set of payment-focused tools, and translates those tool calls into authenticated requests to the MoltPe API. The LLM never sees your API key, never touches a private key, and never signs a transaction directly. It only picks tools and arguments. MoltPe handles custody, policy enforcement, gas, and on-chain settlement — giving you a clean separation between the reasoning layer and the financial layer. For more on the broader category, see what are AI agent payments.

Connecting MoltPe to Claude Desktop

Claude Desktop was the first widely-used MCP client and is still the smoothest way to experiment with agent payments interactively. Setup takes about two minutes.

Step 1: Edit claude_desktop_config.json

Open Claude Desktop's config file. On macOS it lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, it is at %APPDATA%\Claude\claude_desktop_config.json. If the file does not exist, create it. Add the following entry under mcpServers:

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

Replace your_key_here with a key generated from your MoltPe dashboard under Developer → API Keys. The -y flag tells npx to install the package without prompting.

Step 2: Restart Claude Desktop

Quit Claude Desktop completely (not just close the window) and relaunch it. On first start, npx will download @moltpe/mcp-server and spawn it as a subprocess. This takes 10–20 seconds the first time. Subsequent starts are instant because the package is cached.

Step 3: Verify the tools appear

Click the tool picker icon (the small hammer) in the chat input. You should see a moltpe section listing seven tools: create_agent_wallet, check_balance, set_spending_policy, send_payment, list_transactions, generate_invoice, and verify_payment. If the section is missing, check Claude Desktop's developer logs (Help → View Logs) for a startup error — usually a missing or invalid API key.

Step 4: Run your first command

In a new chat, type: "Create a test agent wallet on Polygon named subscription-killer." Claude will call create_agent_wallet, print the returned wallet ID and address, and confirm in plain English. You now have a live, fundable, policy-gated wallet controlled by natural language.

Connecting to Cursor

Cursor added MCP support in early 2025. The config file lives at ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project root (per-project, preferred for CI-friendly setups). The JSON structure is identical to Claude Desktop's:

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

After saving, open Cursor's command palette (Cmd+Shift+P), run MCP: Reload Servers, and verify the moltpe tools appear under Settings → Features → MCP. In Cursor, agent payments are especially useful inside Composer — you can let the agent pay for an x402-metered API while it writes the integration code that consumes it, all in one loop.

One tip for Cursor: put project-specific wallet keys in .cursor/mcp.json and add that file to .gitignore. A separate team-wide key in ~/.cursor/mcp.json covers any workspace without its own config.

Connecting to Windsurf

Windsurf (by Codeium) stores its MCP config at ~/.codeium/windsurf/mcp_config.json. Same JSON shape:

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

Reload via the Windsurf command palette (Windsurf: Refresh MCP). Tools appear in the Cascade sidebar. Windsurf's multi-file agent is particularly good at coordinating several MoltPe wallets at once — handy for marketplace-style agents.

The MoltPe MCP Tool Surface

The MoltPe MCP server exposes seven tools. Each is intentionally narrow — one job, clear arguments, structured results — so the LLM does not have to guess at semantics. Here is the full surface.

create_agent_wallet(chain, name)

Creates a new isolated agent wallet on the specified chain (polygon, base, or tempo). Returns a wallet ID and the on-chain address. Agent example: "Make me a new Base wallet called research-bot." → tool call with chain: "base", name: "research-bot".

check_balance(wallet_id)

Returns the USDC balance and native gas token balance for a wallet. Agent example: "How much does research-bot have left?" → tool call resolving the name to a wallet_id, then returning balance in USDC.

set_spending_policy(wallet_id, daily_cap, per_tx_cap, allowlist)

Configures hard limits for a wallet. daily_cap and per_tx_cap are in USDC. allowlist is an optional array of recipient addresses; if set, payments outside the list are rejected. Agent example: "Cap research-bot at $5 per transaction and $20 per day." → tool call with those values.

send_payment(wallet_id, to, amount, reference)

Initiates a USDC transfer from the wallet to the recipient address. reference is a free-text memo stored in the transaction log. The tool returns only after on-chain settlement, with the transaction hash. Fails with a structured error if the payment would breach policy. Agent example: "Send $3 to 0x8f2e... for the data query." → policy check, then signed transfer.

list_transactions(wallet_id, limit)

Returns the most recent transactions for a wallet, newest first. Each entry includes timestamp, direction, counterparty, amount, reference, and status. Agent example: "Show me what research-bot spent today." → tool call with limit: 20, filtered client-side by date.

generate_invoice(amount, reference)

Creates a pay-to link that another agent or human can settle in USDC. Returns an invoice ID and a hosted URL. Agent example: "Generate an invoice for $12 tagged 'april consulting'." → tool call, agent pastes the returned URL into the reply.

verify_payment(invoice_id)

Checks whether an invoice has been settled and returns the paying address and transaction hash if so. Useful for gating downstream work. Agent example: "Has invoice INV-8821 been paid?" → tool call, returns status: "paid" or "pending".

For the deeper protocol layer underneath these tools — the HTTP-native 402 Payment Required pattern used for per-request billing — see the x402 protocol guide.

A Real End-to-End Example

Here is a lightly-edited transcript of a developer using Claude Desktop to set up an AI agent that hunts down and cancels unused SaaS subscriptions. The agent needs a small float of USDC to pay for a lookup API and to settle cancellation fees on services that charge one.

USER: I want to build a subscription-killer agent. Create a wallet for it
      on Polygon, cap it tight, and fund it with my main wallet.

CLAUDE: Happy to. I'll start with a fresh wallet.
        [tool: create_agent_wallet chain="polygon" name="sub-killer"]
        → wallet_id: wal_9f2a, address: 0x4c8d...a102

        Now a tight policy. What's a reasonable per-transaction and
        daily ceiling? For a first run I'd suggest $5 per tx and $25/day.

USER: Go with that. No allowlist yet — I want to see where it pays.

CLAUDE: [tool: set_spending_policy wallet_id="wal_9f2a"
         daily_cap=25 per_tx_cap=5 allowlist=null]
        → policy applied.

        What's your main wallet ID so I can draft a funding transfer?

USER: wal_main. Send $30 from there to sub-killer.

CLAUDE: [tool: send_payment wallet_id="wal_main" to="0x4c8d...a102"
         amount=30 reference="fund sub-killer initial float"]
        → tx: 0xabc123..., settled in 2.1s.

        Balance check on sub-killer:
        [tool: check_balance wallet_id="wal_9f2a"]
        → 30.00 USDC, 0.05 MATIC for gas.

        Sub-killer is live. It has $30, a $5 per-tx cap, and a $25 daily
        cap. Want me to set the allowlist once we know the cancellation
        endpoints, so nothing unexpected leaks out?

USER: Yes, do that after the first successful cancellation.

Two things worth noting. First, the LLM picked the right tools in the right order without scripting — that is MCP's payoff. Second, every financial action went through a policy-gated tool call, not a raw signature. The agent cannot exceed caps even if a later instruction asks it to.

Multi-Agent Patterns with MCP

A single MCP connection can manage many wallets. That matters more than it sounds. You can give each sub-agent or sub-task its own isolated wallet with a policy tuned to its role — a research agent with a $10/day cap, a deployment agent with a $200/day cap, a marketplace-seller agent with no outbound allowance at all (receive-only). All seven tools take a wallet_id, so the same MCP session can fluidly switch between them.

This composes naturally with external agent-to-agent payments. When your agent needs to call a paid external service, the same MCP surface hands off to x402: the LLM calls send_payment (or a higher-level call_x402_endpoint wrapper if you have the extended tool set enabled), and MoltPe handles the 402 negotiation, signing, and retry. The agent does not need to know whether the counterparty is a human merchant, another MoltPe agent, or a stranger's x402-gated API. It is all one tool call.

For teams running dozens of agents, this is the cleanest pattern we have seen: one MCP server per client, many wallets per server, policies as code, and the LLM never touches custody. For a practical walkthrough of end-to-end setup, see the 5-minute developer quickstart, or read why developers choose MoltPe.