Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@open-payments-mcp Create an incoming payment for 100 USD"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Standalone MCP server exposing core Open Payments operations over stdio.
get_wallet_address
request_grant
continue_grant
create_incoming_payment
get_incoming_payment
create_quote
get_quote
create_outgoing_payment
get_outgoing_payment
Related MCP server: Beep MCP Server
Set these environment variables before running:
export OPEN_PAYMENTS_CLIENT_ADDRESS="https://example.com/client"
export OPEN_PAYMENTS_PRIVATE_KEY_PATH="/absolute/path/to/private.key"
export OPEN_PAYMENTS_KEY_ID="your-key-id"Optional:
export OPEN_PAYMENTS_SESSION_FILE=".data/open-payments-sessions.json"
export OPEN_PAYMENTS_CALLBACK_PORT="3999"
export OPEN_PAYMENTS_MAX_DEBIT_AMOUNT="100000"You can start from .env.example if you prefer loading env vars with your MCP client or shell.
The private key path, key ID, access tokens, and grant continuation tokens are never accepted as MCP tool inputs and are not returned in MCP tool responses.
pnpm install
pnpm build
pnpm startFor development:
pnpm devTypical peer-style flow using the core tools:
get_wallet_address for receiver and sender.
request_grant for receiver incoming-payment access.
create_incoming_payment.
request_grant for sender quote access.
create_quote.
request_grant for sender outgoing-payment access.
User opens interactRedirectUrl and approves in their wallet.
continue_grant.
create_outgoing_payment.
get_outgoing_payment.
Outgoing payment execution requires the finalized grant produced after user approval.
Continue an interactive Open Payments grant after the user approves it.
Inputs: grantSessionId (required), interactRef.
Create an incoming payment using a finalized incoming-payment grant session.
Inputs: grantSessionId (required), receiverWalletAddress (required), expiresAt, description, +1 more.
Create an outgoing payment using a finalized outgoing-payment grant session.
Inputs: quoteId (required), grantSessionId (required), senderWalletAddress (required), description.
Create a quote using a finalized quote grant session.
Inputs: receiver (required), grantSessionId (required), senderWalletAddress (required), method, +2 more.
Orchestrate a full peer-to-peer payment flow: incoming payment, quote, interactive outgoing grant, and outgoing payment (blocks until approval).
Inputs: sendingWalletAddressUrl (required), receivingWalletAddressUrl (required), dryRun, method, +2 more.
Read incoming payment details using a finalized incoming-payment read grant.
Inputs: grantSessionId (required), incomingPaymentUrl (required).
Read outgoing payment details using a finalized outgoing-payment read grant.
Inputs: grantSessionId (required), outgoingPaymentUrl (required).
Read quote details using a finalized quote read grant.
Inputs: quoteUrl (required), grantSessionId (required).
Resolve an Open Payments wallet address and return sanitized wallet details.
Inputs: walletAddress (required).
Request an Open Payments grant. Outgoing payment grants are made interactive and return an approval URL.
Inputs: access (required), authServer (required), interact.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 10 tools
Most tools map clearly to distinct resources and actions (e.g., create_incoming_payment vs. create_outgoing_payment, get_quote vs. get_outgoing_payment). The composite tool execute_peer_to_peer_payment could be confused with the individual step tools, but its description clearly frames it as an orchestration workflow.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_wallet_address, create_incoming_payment, request_grant). The verbs and resource names are uniform and predictable.
With 10 tools, the server is well-scoped for the Open Payments domain. It covers the essential resources (wallet address, grants, incoming payments, quotes, outgoing payments) and includes a high-level workflow tool without becoming bloated.
The tool set provides create and read coverage for all major resources and handles the grant lifecycle. However, there are no list operations (e.g., list incoming payments) or cancellation/update capabilities, which constitutes a minor gap for a full payment workflow.
Discover machine-payable APIs, probe x402 payment terms, and run seller operations. Non-custodial.
Pay for APIs with USDC. Read-only x402 payment discovery, verification, evidence, and status.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Invoicing, expenses, accounting analytics. OAuth 2.1 dynamic client registration, no API key.
