Stables MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STABLES_API_KEY | Yes | Your Stables API key | |
| STABLES_API_URL | No | API base URL. Must use HTTPS. | https://api.sandbox.stables.money |
| TWILIO_AUTH_TOKEN | No | Twilio Auth Token (required for send_verification_sms) | |
| TWILIO_ACCOUNT_SID | No | Twilio Account SID (required for send_verification_sms) | |
| TWILIO_PHONE_NUMBER | No | Twilio phone number to send from (required for send_verification_sms) |
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_customerB | Create a new customer in Stables for KYC verification and transfers. Use 'individual' for personal accounts or 'business' for company accounts. Include entitlements like 'base_payout' to enable transactions. |
| create_customer_onboarding_linkA | Create a customer and get a hosted verification link for them in one call, so the customer enters their own KYC/KYB details. An existing customer with the same email is reused (customer_created is false) and the fields sent are ignored. Takes the same fields as create_customer; send what you already know. |
| get_customerC | Get details about a specific customer including their verification status |
| list_customersA | List customers for the authenticated tenant. Without pageSize the API returns its default first page; pass pageSize and follow pageToken to read them all |
| get_verification_linkB | Generate a KYC verification link for a customer. The customer must complete verification before they can make transfers. |
| update_customerC | Update customer details, entitlements, or verification information |
| update_customer_metadataC | Update customer metadata key-value pairs |
| create_quoteA | Get a quote for a currency exchange: the rate, the fees, and what the customer receives. Quotes are short-lived, so create one immediately before the transfer. Off-ramp converts a stablecoin to fiat (source network required, destination country required); on-ramp converts fiat to a stablecoin (destination address required). Set preview to price without committing. |
| get_quoteA | Get details about an existing quote including its current status |
| create_transferA | Execute a transfer using an active quote. The quote must not be expired. This initiates real money movement, so get explicit human approval first. For payouts in AED, CAD, EUR, GBP, MXN, USD you must also supply recipientType, the full beneficiary address, and dateOfBirth when the recipient is an individual. |
| validate_payment_methodA | Check bank payout details against the corridor's rules without creating anything. Use it before create_transfer to find out which fields a currency needs (beneficiary address, date of birth, bank codes), instead of spending a short-lived quote on a rejected transfer. |
| get_transferA | Get the current status and details of a transfer |
| list_transfersC | List transfers with optional filters for status, type, or customer |
| create_virtual_accountA | Create a payment route (virtual bank account) so a customer can receive fiat deposits that convert to a stablecoin and pay out to a wallet. The payout destination is mandatory: the API refuses a fiat-to-crypto route without one. Deposit handling is set server-side and defaults to auto_payout; change it afterwards with update_virtual_account. |
| list_virtual_accountsA | List payment routes (virtual accounts) for one customer, or across every customer when customerId is omitted |
| list_route_whitelistB | List the bank accounts whitelisted to pay into an AUD payment route. Some Australian routes only accept deposits from whitelisted source accounts. |
| add_route_whitelist_accountC | Whitelist an Australian bank account (BSB and account number) to pay into an AUD payment route. |
| update_route_whitelist_accountA | Change or disable a whitelisted source account on an AUD payment route. Send the full record: BSB, account number and status. |
| update_virtual_accountC | Update virtual account settings (e.g., deposit handling mode) |
| get_virtual_account_historyC | Get the activity history for a virtual account (deposits, payouts, etc.) |
| update_route_destinationA | Change the payout wallet on an existing payment route. Deposits after this point are paid out to the new address; use it when a customer rotates wallets rather than creating a second route. |
| register_route_payidA | Register a PayID for an activated AUD payment route, so payers can send to an email-style alias instead of a BSB and account number. Calling it again on a route that already has one returns the existing PayID. |
| create_api_keyA | Create a new API key for accessing the Stables API. The secret key is only shown once on creation - save it immediately. |
| list_api_keysB | List all API keys for the current account |
| get_api_keyB | Get details about a specific API key |
| revoke_api_keyA | Revoke an API key. This permanently disables the key and cannot be undone. |
| create_webhookA | Subscribe to Stables events via webhook. You'll receive POST requests to your URL when events occur. Event types are dotted and lowercase. Use 'all' to receive everything. Security: Set a secret to enable HMAC-SHA256 signature verification via X-Webhook-Signature header. |
| list_webhooksA | List all webhook subscriptions for the current account |
| delete_webhookA | Delete a webhook subscription. You will stop receiving events at this endpoint. |
| list_webhook_deliveriesA | List recent webhook delivery attempts with their HTTP status and retry state. This is the first place to look when an integration is not receiving events: it shows whether Stables sent them and what the endpoint answered. |
| get_balanceA | Get your organisation's stablecoin balance, one entry per asset and network held. Also says whether transfers may be paid from it (transfers_enabled), which create_transfer with fundingSource 'prefund_balance' needs. |
| get_balance_walletA | Get the deposit wallet that tops up your balance on one network, and its status. The address is only present once the status is 'active'. |
| create_balance_walletA | Create the deposit wallet that tops up your balance on a network. Creation is asynchronous: the first answer is 'creating'; poll get_balance_wallet until it is 'active'. Safe to call again while creation is in flight. |
| list_balance_activityA | List deposits that have credited your balance, newest first, with amount, network, transaction hash and sender. |
| list_pending_balance_depositsA | List deposits seen on-chain but held before crediting your balance, with the reason: the sender is not a whitelisted wallet, or compliance review. |
| list_whitelisted_walletsA | List the wallets whitelisted to deposit into and receive withdrawals from your balance. Only 'active' wallets can. Whitelisting a wallet is done in the dashboard; there is no API for it. |
| list_available_entitlementsB | List the entitlements (products and payment rails, e.g. 'aed_local') a customer has not applied for yet, whether each is available to them now, and the verification it needs. |
| request_entitlementsA | Apply for one or more entitlements for an existing customer, e.g. to add a payment rail. Check list_available_entitlements first. If Stables needs more verification, the response lists what is missing; send it with submit_entitlement_requirements. |
| submit_entitlement_requirementsA | Send further verification data Stables asked for on a requested entitlement. The fields are those of the customer record in snake_case (e.g. tax_id_number, address, financial_profile, id_documents, proof_of_address_documents); send only what is missing. Documents are base64 data. |
| list_rfisA | List the organisation's compliance requests for information (RFIs), newest first: what Stables compliance needs before it releases a held payment or verification. Open and submitted ones by default. Check this when a transfer or deposit is held, or subscribe to the rfi.* webhooks. |
| list_customer_rfisB | List one customer's compliance requests for information (RFIs), with what each requirement needs next. |
| get_rfiA | Get one compliance request for information (RFI): why it was raised, its requirements and how to answer each. |
| get_rfi_evidence_formA | Get the form an |
| submit_rfi_evidenceA | Submit the answers and documents an |
| get_kyc_capabilitiesA | List the verification capabilities a customer holds (for example proof_of_address), the level that granted each, and when. A |
| add_documentA | Attach a supporting document (invoice, contract or other) to a transfer or a payment route deposit, for example when Stables compliance asks for one. The file goes as a base64 data URL ('data:application/pdf;base64,...'). |
| list_documentsA | List the documents attached to a transfer or a payment route deposit, newest first. |
| get_document_download_urlA | Get a short-lived link to download a document attached to a transfer or a payment route deposit. |
| delete_documentA | Remove a document from a transfer or a payment route deposit. This cannot be undone, so confirm with a human first. |
| simulate_route_depositA | SANDBOX ONLY. Simulate a fiat deposit into a payment route so you can watch the conversion and payout complete without a real bank transfer. Fails on production. |
| simulate_transfer_depositA | SANDBOX ONLY. Simulate the customer sending the crypto an off-ramp transfer is waiting on, so the transfer can progress to payout without an on-chain payment. Fails on production. |
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 51 tools
Most tools map to a distinct resource+action, and the descriptions actively disambiguate near-pairs such as list_rfis vs list_customer_rfis, create_customer vs create_customer_onboarding_link, get_verification_link vs the onboarding link, and validate_payment_method vs create_transfer. The main friction is the same entity being called both a 'virtual account' and a 'payment route' (create_virtual_account vs update_route_destination), plus several update_* tools on routes that require reading descriptions to tell apart.
Nearly everything follows a clear snake_case verb_noun pattern (list_/get_/create_/update_/delete_/add_/submit_/simulate_). Minor deviations: request_entitlements is a bare verb with no noun, and the vocabulary drifts between 'virtual_account' and 'route' for the same object, so the names alone are not fully predictable.
51 tools is a large surface, well past the 15-tool comfort band, and the agent must choose among many closely related CRUD endpoints. The domain genuinely is broad (customers, KYC, quotes, transfers, routes, RFIs, entitlements, documents, webhooks, balance), so the tools are not gratuitous, but the count is still heavy for reliable selection.
Coverage is strong across the lifecycle: customers (create/update/metadata/onboarding link), transfers (create/get/list), quotes (create/get), routes (create/update/list/history/whitelist/payid), documents (add/list/download/delete), webhooks, API keys, balance, entitlements and RFIs. Gaps are modest but real: no cancel/refund a transfer, no delete/close a payment route, and no get/update for an individual webhook.