stablevoy-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STABLEVOY_API_KEY | No | One store key; when set, the login keys are not used. | |
| STABLEVOY_API_URL | No | The API URL, `https://api.stablevoy.com` by default. | https://api.stablevoy.com |
| STABLEVOY_MCP_PROFILE | No | Which login profile to use, `default` by default. | default |
| STABLEVOY_MCP_READ_ONLY | No | Set to `true` to leave create_invoice out. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Stablevoy is a non-custodial USDT and USDC payment gateway. These tools create invoices to receive money and read stores and invoices. They cannot move funds or change any setting: payout addresses, webhooks, limits, keys and stores are changed by the merchant in the Stablevoy dashboard. Amounts are US dollars as decimal strings.
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 |
|---|---|
| list_storesA | Lists the Stablevoy stores this server can work with. Returns stores: one entry per connected store with id, name, status, enabledNetworks, canAcceptPayments and evmPayoutStatus, or an error for a store whose key no longer works. Call it first to learn store names for the store argument of the other tools; use get_store for the full settings of one store. |
| get_storeA | Gets one store with its settings: status, enabled networks, networks without a payout wallet, payout addresses, the EVM payout status and the networks it blocks, invoice limits (store, platform and the range in effect), fee, website, return and webhook URLs. Call it first when create_invoice fails or a store cannot accept payments; use list_stores to see all stores briefly. Read only: settings change in the Stablevoy dashboard. |
| get_invoiceA | Gets one invoice by its id when you already have the id, for example from create_invoice or list_invoices. Returns id, status, amountUsd, reference, createdAt, expiresAt, paidAt, holdReason, networks and payments (network, token, amount in the token's smallest units, txHash, status, detectedAt). Without store it looks in every connected store; an id no store has gives a not_found error. To find invoices by status, reference or date, use list_invoices. |
| list_invoicesA | Lists invoices newest first, to find invoices when you do not have an id: filter by status, source, a search (invoice id or the start of the reference) and the UTC days they were created. Returns pages: for each store its name, invoices (the same fields as get_invoice) and nextCursor, null on the last page. One page per call; pass nextCursor as cursor together with the same store to get the next page. Without store and with several stores, one page per store. No match gives an empty list, not an error. Use get_invoice for one invoice by id. |
| create_invoiceA | Creates a Stablevoy invoice the buyer pays in USDT or USDC, and returns its payment link (checkoutUrl). Give a reference (for example "acme-october") whenever you can: the same amount and reference return the same invoice instead of a second one. Without a reference every call creates a new invoice. Check the result later with get_invoice. |
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 5 tools
Each tool has a clearly distinct resource and action: list_stores vs get_store, and list_invoices vs get_invoice vs create_invoice. The descriptions explicitly explain when to use each alternative, leaving no meaningful overlap.
All five tools follow a consistent snake_case verb_noun pattern: list_stores, get_store, list_invoices, get_invoice, create_invoice. There are no mixed conventions or vague verbs.
Five tools is a reasonable, focused surface for store and invoice operations. It is slightly thin in that stores are read-only and invoices lack lifecycle actions, but every included tool has a clear purpose.
The server covers listing stores, inspecting store settings, creating invoices, and retrieving/listing invoices. However, invoice lifecycle operations such as canceling, updating, or refunding are absent, and store settings are read-only by design, leaving notable gaps for agents handling payment workflows.