Skip to main content
Glama
Payagents

PayAgents MCP Server

Official
by Payagents

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PAYAGENTS_API_KEYYesYour 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues