Cosmos Pay MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COSMOS_PAY_API_KEY | Yes | Required. A secret API key from the Cosmos Pay dashboard: a `dv_` key works on test networks with no real money, a `prod_` key works on mainnet. | |
| COSMOS_PAY_API_URL | No | Another Payments API root. | https://api.cosmospay.lat/cosmos-api |
| COSMOS_PAY_READ_ONLY | No | Set to `1` to offer only the tools that read (no create, validate or delete). | |
| COSMOS_PAY_CHECKOUT_URL | No | Another hosted checkout origin. | https://payments.cosmospay.lat |
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 |
|---|---|
| get_paymentA | Read one payment: its status (PENDING, SUBMITTED, SUCCEEDED, FAILED, CANCELLED, EXPIRED), amount, asset, chain, destination, payment link, hosted checkout URL and, once paid, the transaction hash. |
| get_payment_historyA | The status changes of one payment, oldest first, with when each happened. |
| list_paymentsA | List the payments of the API key’s organization, newest first, optionally filtered by status, chain or creation date. Paged: |
| create_payment_linkA | Create a payment request that a customer pays from their own wallet: a payment link (SEP-7 on Stellar, Solana Pay on Solana, EIP-681 on Monad), its QR code and a hosted checkout page. It moves no money: the payment settles on-chain straight to |
| validate_paymentA | Check a transaction against a payment and settle it if it pays it. Use it when the payer sent the payment but its status has not changed: pass the transaction hash (or Solana signature) the payer has. |
| delete_paymentA | Delete a payment that is not paid, so its link can no longer be paid. A paid (SUCCEEDED) payment cannot be deleted. This cannot be undone: confirm with the user first. |
| get_summaryB | Overview of the API key’s organization: payment totals, settled volume, webhook health and a 30-day series. |
| get_balancesA | Settled and pending amounts per asset for the API key’s organization (what its payments brought in, not a wallet balance). |
| list_stellar_assetsA | The Stellar asset catalog: codes and issuers to charge in (for example USDC and EURC by Circle). Use an entry’s code and issuer as create_payment_link’s asset_code and asset_issuer. |
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 action (retrieve, list, create, validate, delete) on payments or org data. Minor overlap between get_summary and get_balances (both org-level overviews), and get_payment vs get_payment_history could occasionally be confused, but descriptions clarify the boundary.
All tools follow a consistent snake_case verb_noun pattern: get_payment, list_payments, create_payment_link, validate_payment, delete_payment, get_summary, etc. No mixed conventions or vague verbs.
Nine tools is well-scoped for a payments API, covering the full lifecycle without redundancy. Each tool earns its place with a clear, non-trivial function.
Create/read/list/validate/delete coverage is solid, plus summary, balances, and asset catalog. However, webhook management (referenced in get_summary's webhook health) and refunds lack dedicated tools, leaving minor gaps.