crypto-payer-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CRYPTO_PAYER_API_URL | No | API URL (default: testnet URL) | |
| CRYPTO_PAYER_ENV_FILE | No | Custom path to .env file | |
| CRYPTO_PAYER_DOMAIN_URL | No | Domain URL (default: testnet URL) | |
| CRYPTO_PAYER_PUBLIC_KEY | Yes | RSA public key for webhook verification (required) | |
| CRYPTO_PAYER_SECRET_KEY | Yes | Secret key from PLATFORM (required) | |
| CRYPTO_PAYER_OPERATOR_ID | Yes | Operator ID from PLATFORM (required) | |
| CRYPTO_PAYER_OPERATOR_NAME | Yes | Your operator display name (required) |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| request_paymentA | Request a new payment session from Crypto Payer PLATFORM. Returns a paymentId that can be used to construct the payment URL. Requires user access token for authentication. |
| generate_auth_headerA | Generate the X-Operator-Authorization header value for PLATFORM API requests. Uses SHA-512 hash of operator credentials encoded in Base64. |
| verify_webhookB | Verify the signature of a webhook event from PLATFORM. Uses RSA-SHA512 signature verification with the operator's public key. |
| build_payment_urlA | Build the complete payment URL for redirecting users to the PLATFORM payment page. Combines the platform domain with paymentId and operator information. |
| parse_webhook_eventB | Parse and extract information from a webhook event. Returns structured data about the transaction including user, amount, network, and status. |
| get_configA | Get the current Crypto Payer configuration (with sensitive values masked). Useful for debugging and verifying environment setup. |
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 6 tools
Each tool targets a distinct action: payment session creation, auth header generation, webhook signature verification, URL construction, webhook parsing, and config retrieval. Even closely related webhook tools are separated by verification versus parsing, and request_payment versus build_payment_url are clearly different stages.
All tool names follow a consistent verb_noun snake_case pattern: request_, generate_, verify_, build_, parse_, get_. There are no mixed conventions or vague verbs.
Six tools is a well-scoped set for a payment integration server. Each tool covers a distinct part of the payment flow without redundancy or bloat.
The set covers the core flow: create a payment request, build the redirect URL, generate API auth, and verify/parse incoming webhooks. A notable gap is the lack of a direct payment-status lookup or cancellation/refund operation, though webhooks may partially cover status delivery.