novapay-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MERCHANT_ID | Yes | Merchant identifier in NovaPay. Required. | |
| NOVAPAY_PUBLIC_KEY | No | NovaPay public key (PEM). Optional and unused in stdio mode. | |
| NOVAPAY_ENVIRONMENT | Yes | NovaPay environment: 'stage' for test (api-qecom.novapay.ua) or 'prod' for production (api-ecom.novapay.ua). Required. | |
| MERCHANT_PRIVATE_KEY | Yes | Merchant's private RSA key (PEM). Signs every request to NovaPay. 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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_keysA | Generate an RSA 2048 keypair for NovaPay merchant onboarding. Returns the PUBLIC key (register it with NovaPay via the Acquiring3 admin panel or NovaPay support) and the file path of the PRIVATE key. The private key itself is never returned. Works without any configuration — this is the first onboarding step. |
| create_acquiring_sessionA | Create a NovaPay Internet Acquiring payment session. Returns the session id. To get a payment URL for the customer, follow up with add_acquiring_payment. A session can hold multiple payments. |
| add_acquiring_paymentA | Add a payment to an existing acquiring session. Returns the payment URL to send to the customer, plus the session and transaction ids. Call again with the same session_id to add more payments. |
| create_checkout_sessionA | Create a NovaPay Checkout session (payment + Nova Poshta delivery collection). Returns the session id. To get a payment URL for the customer, follow up with add_checkout_payment. |
| add_checkout_paymentA | Add a payment to an existing checkout session. Returns the checkout URL to send to the customer plus the session id (the transaction id appears later in get_session_status). |
| get_session_statusA | Get the current status of a payment session (acquiring or checkout): lifecycle status (created/holded/paid/voided/expired/...), transaction status, amounts (decimal strings) and the list of payment operations. Use this to poll for payment results and to verify the outcome of complete_hold / void_session / expire_session. |
| complete_holdA | Capture funds previously held with use_hold=true, moving the session from holded to paid. Optionally capture a smaller amount than was held. NovaPay returns no body for this call — check the result with get_session_status. |
| void_sessionA | Cancel a PAID or HELD session: releases a hold or REFUNDS an already charged payment — real money moves back to the customer. Confirm with the user before calling this on a paid session. For unpaid sessions use expire_session instead. NovaPay returns no body — check the result with get_session_status. |
| expire_sessionA | Invalidate an UNPAID session so its payment URL can no longer be paid. Use this to cancel a payment link that was created by mistake or is no longer needed. NovaPay returns no body — check the result with get_session_status. |
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 9 tools
Each tool targets a distinct resource/action: key generation, two session creation flows, two payment addition flows, status retrieval, and three lifecycle operations. The distinction between acquiring and checkout sessions is clear, and void/expire/complete_hold have explicit use-case boundaries.
All tool names follow a consistent verb_noun pattern in snake_case (generate_keys, create_acquiring_session, add_checkout_payment, etc.). The verbs and objects are uniformly structured, with no mixed casing or naming style deviations.
With 9 tools, the set is well-scoped for a payment processing server. Each tool serves a distinct step in the payment lifecycle—onboarding, session creation, payment addition, status polling, and post-payment actions—without redundancy or bloat.
The tool set covers the full payment session lifecycle: key generation, session creation for both acquiring and checkout, payment addition, status tracking, and resolution via hold completion, void, or expiration. There are no obvious dead ends or missing operations for the stated purpose.