zen-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZEN_ENV | No | Environment: sandbox (default) or production. | sandbox |
| ZEN_MOCK | No | Set to '1' or 'true' to enable deterministic offline responses without a real account. | false |
| ZEN_API_KEY | No | Terminal API Key sent in Authorization without a Bearer prefix. Required outside mock mode. | |
| ZEN_BASE_URL | No | API base URL override; takes priority over ZEN_ENV. | |
| ZEN_HASH_ALG | No | Hash algorithm: sha224, sha256 (default), sha384, or sha512. | sha256 |
| ZEN_IPN_SECRET | No | IPN secret used only by verify_webhook_signature. | |
| ZEN_PAYWALL_SECRET | No | Checkout/paywall secret used to sign request bodies. Required for write operations. |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_payment_methodsA | Read-only: list payment methods available to the configured ZEN terminal. |
| get_transactionA | Read-only: retrieve a transaction by exactly one ZEN ID or merchant transaction ID. |
| list_payment_linksB | Read-only: list hosted ZEN payment links. |
| get_payment_linkA | Read-only: retrieve a hosted ZEN payment link by ID. |
| get_payoutA | Read-only: retrieve a ZEN payout by its ZEN ID. |
| download_reportB | Read-only: request a transaction or settlement report download from ZEN. |
| list_supported_currenciesA | Read-only: list currencies confirmed in the public ZEN documentation. |
| create_payment_linkC | Write operation: create a hosted ZEN checkout link and QR code for a customer to pay. |
| refund_transactionA | Destructive write: return all or part of a payment to the customer. Confirm the transaction and amount before use. |
| capture_transactionA | Destructive write: capture an authorized transaction, causing funds to be collected. Confirm before use. |
| cancel_transactionB | Destructive write: cancel a ZEN transaction. This may prevent or reverse payment processing; confirm before use. |
| create_payoutA | Highest-risk destructive write: send money outward through ZEN. Verify recipient, channel, currency, and amount before use. |
| create_customerC | Write operation: create a customer record in ZEN for future payment flows; this stores personal data. |
| verify_webhook_signatureA | Read-only: verify a ZEN IPN webhook signature using the configured IPN secret. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| payment-methods | Snapshot of payment methods available to the configured ZEN terminal. |
| currencies | Currencies confirmed in the public ZEN documentation. |
TDQS
Scored across 14 tools
Each tool targets a distinct resource and action: payment methods, transactions, payment links, payouts, reports, currencies, customers, and webhook verification are clearly separated. Even similar operations like refund, capture, and cancel are differentiated by their descriptions and intended effects.
All tool names follow a consistent verb_noun pattern in snake_case, using clear verbs such as list, get, create, refund, capture, cancel, download, and verify. There are no mixed conventions or vague action words.
With 14 tools, the server is well-scoped for a payment platform covering transactions, payment links, payouts, reports, and customers. Each tool provides a meaningful capability without unnecessary redundancy or bloat.
Core payment workflows are well covered: creating/retrieving payment links, retrieving and managing transactions, creating/retrieving payouts, downloading reports, and verifying webhooks. Minor gaps exist, such as no list transactions endpoint, no update/delete for payment links, and no customer read/update operations, but these are workable.