cryptunnel-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CRYPTUNNEL_API_KEY | Yes | Your API key. Required. | |
| CRYPTUNNEL_BASE_URL | No | Point the server at another API host, for a local backend. | |
| CRYPTUNNEL_ALLOW_LIVE | No | Set to 1 to allow real payments. Unset by default. Even then a payment is a sandbox one unless the agent passes is_test: false explicitly. | |
| CRYPTUNNEL_MERCHANT_ID | Yes | Your public merchant id. Required - the server exits naming it when missing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_paymentA | 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. |
| get_paymentA | 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. |
| list_paymentsA | 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. |
| list_currenciesA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.