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., "@cryptunnel-mcp create a sandbox payment for 10 USD for order test-1 and give me the checkout link"
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.
An MCP server that lets a coding agent - Claude Code, Cursor, anything speaking the Model Context Protocol - create and look up Cryptunnel crypto payments. Build a payment integration by prompting: "create a sandbox payment for 10 USD and give me the checkout link".
It runs on your machine over stdio, wraps the cryptunnel
client, and talks to nothing but api.cryptunnel.io. No hosted service, no OAuth.
You need your merchant id and an API key, both from the merchant page in the cabinet. Node 20+.
claude mcp add cryptunnel \
--env CRYPTUNNEL_MERCHANT_ID=<merchant id> \
--env CRYPTUNNEL_API_KEY=<api key> \
-- npx -y cryptunnel-mcpOr, to share it with a project, in .mcp.json at the repository root:
{
"mcpServers": {
"cryptunnel": {
"command": "npx",
"args": ["-y", "cryptunnel-mcp"],
"env": {
"CRYPTUNNEL_MERCHANT_ID": "<merchant id>",
"CRYPTUNNEL_API_KEY": "<api key>"
}
}
}
}In .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"cryptunnel": {
"command": "npx",
"args": ["-y", "cryptunnel-mcp"],
"env": {
"CRYPTUNNEL_MERCHANT_ID": "<merchant id>",
"CRYPTUNNEL_API_KEY": "<api key>"
}
}
}
}Create a sandbox payment for 10 USD for order
test-1and give me the checkout link.
The agent calls create_payment, and the link opens the checkout page listing testnet coins. If the
list is empty, attach a testnet wallet to the merchant in the cabinet first - see
Sandbox and faucets.
Related MCP server: Yolfi MCP server
Variable | Meaning |
| Your public merchant id. Required - the server exits naming it when missing |
| Your API key. Required |
| Set to |
| Point the server at another API host, for a local backend |
An agent holding a live key must not be one prompt away from a real invoice. So by default every
payment this server creates is a sandbox payment: the buyer is offered testnet coins only, nothing
is charged, and the payment stays out of your stats. Asking for is_test: false is refused with a
message that names the variable - the payment is not silently downgraded, the agent is told why.
Set CRYPTUNNEL_ALLOW_LIVE=1 to let the agent create real payments. Even then a payment is a
sandbox one unless the agent passes is_test: false explicitly.
Tool | What the agent gets |
| A checkout url for a given amount and currency, keyed by your |
| One payment by id, with its status - deliver on |
| The merchant's payments, newest first, paged |
| The currencies the merchant can receive - only those with an active wallet |
Every tool returns the API response as JSON text; an API error comes back as a tool error carrying
the API code, e.g. ValidationError (WALLET_NOT_FOUND): Wallet not found.
cryptunnel client the server wraps
Support: GitHub Issues
MIT licensed.
Create a Cryptunnel payment and get a checkout url to send the buyer to. On that page the buyer picks a cryptocurrency and pays straight to the merchant's own wallet. Use it whenever someone has to be charged. Returns the payment id (keep it - get_payment needs it), the checkout url and the status "created". By default the payment is a sandbox payment: the buyer is offered testnet coins only and nothing real moves. Repeating an external_id returns the payment already created for it instead of a second one.
Inputs: amount (required), currency (required), external_id (required), is_test, +4 more.
Look up one payment by the id create_payment returned. The status says where it stands: "created" - waiting for the buyer to pick a coin; "pending" - coin picked, transfer awaited; "confirmed" or "confirmed_manual" - paid, safe to deliver; "failed"; "expired". Only a payment past "created" carries a crypto amount, currency and wallet address.
Inputs: id (required).
List the cryptocurrencies this merchant can actually receive - only currencies with an active wallet appear, each with its blockchain. An empty list means no wallet is attached for that family yet; a testnet wallet has to be attached in the cabinet before a sandbox payment can be paid.
Inputs: is_test.
List the merchant's payments, newest first, with paging. Use it to find a payment when you only know your own order id (external_id), or to review recent activity. Test and live payments are listed together - check is_test on each.
Inputs: limit, offset.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 4 tools
Each tool targets a distinct operation on a distinct resource: create_payment (create checkout), get_payment (single lookup by id), list_payments (paged enumeration), list_currencies (static currency catalog). No two tools overlap in purpose and the descriptions reinforce the boundaries (e.g. get_payment needs the id from create_payment).
Consistent snake_case verb_noun pattern throughout (create_payment, get_payment, list_payments, list_currencies). The singular/plural resource suffix follows a predictable creates-one vs lists-many convention.
Four tools is slightly thin but well-matched to a narrowly scoped payment-checkout surface. Each tool earns its place with no redundancy, though the set is at the low end of the typical 3-15 range.
Covers the core accept-a-payment lifecycle: create checkout, poll status (created→pending→confirmed/failed/expired), enumerate by external_id, and enumerate receivable currencies. No explicit cancel/refund tool, but these are plausibly out of scope for a checkout-only surface, so only a minor gap remains.
Crypto payments for AI agents: self-serve account, invoices, receiving, payouts, exchange.
Keyless non-custodial crypto payments for AI agents: payment links and tip jars, no API key.
Crypto pay links and API for people and AI agents. BTC, Lightning, USDC, USDT, EURC, SOL, ETH.
Non-custodial crypto payments for AI assistants: balances, payments, and create payment links.
