PayAgents MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAYAGENTS_API_KEY | Yes | Your PayAgents API key (e.g. pa_live_your_api_key_here). Used to authenticate the MCP server with PayAgents. |
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 |
|---|---|
| payagents_pay_urlA | Execute a request to an HTTP API endpoint or paywalled resource, automatically resolving and paying any HTTP 402 / L402 Lightning or x402 Base USDC micro-payment challenges within your spending policy. |
| payagents_get_balanceA | Retrieve the current PayAgents spending balance, subscription tier, and active enterprise spending policy limits (per-transaction and daily limits). |
| payagents_get_transactionA | Lookup the status, rail (Lightning / Base USDC), settlement mode (Direct vs Managed), and cryptographic proof for a specific PayAgents transaction ID. |
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 3 tools
Each tool targets a distinct action: payment execution, balance retrieval, and transaction lookup. There is no functional overlap—pay_url performs a side-effectful operation while the other two are read-only queries. An agent can easily distinguish them by purpose.
All tools follow a consistent 'payagents_verb_noun' pattern (pay_url, get_balance, get_transaction). The prefix identifies the server, and the verb/noun structure is uniform across the set, making the naming predictable and clear.
With three tools, the server is at the lower end of the typical range, but it appropriately covers the essential operations for its purpose: making a payment, checking balance, and verifying transaction status. The count feels slightly thin but is justified given the narrow domain.
The tool surface covers the core workflow: pay, check balance, and look up transaction details. Minor gaps exist, such as listing all transactions or managing spending policies directly, but these are unlikely to cause agent failures for the intended use case. The absence of an update/delete pattern is acceptable since payments are immutable.