paybot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAYBOT_BOT_ID | No | Default bot identifier. | mcp-agent |
| PAYBOT_API_KEY | Yes | PayBot API key. Required; without it every tool call fails with a 401. | |
| PAYBOT_WALLET_KEY | No | Wallet private key for real payments. Optional; omitting keeps the underlying SDK in mock mode (no on-chain settlement). | |
| PAYBOT_FACILITATOR_URL | No | Facilitator server URL. | https://api.paybotcore.com |
| PAYBOT_ENABLE_DEMO_TOOLS | No | Register the governed mock demo tools (`delete_database`, `annotate_record`). Must be exactly `true`. | false |
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 |
|---|---|
| paybot_payB | Make a payment (USDC by default) for an API, service, or resource. Returns transaction hash and commission breakdown. Supports alternate tokens and idempotency. |
| paybot_balanceB | Check spending limits, trust level, and remaining daily budget for a bot. |
| paybot_historyB | View recent payment history and audit events for a bot. |
| paybot_registerA | Register a new bot with the PayBot facilitator. Returns the assigned trust level. Supports an optional idempotency key for safe re-issue. |
| paybot_list_networks_and_tokensA | List the networks and tokens PayBot supports. Read-only, offline, requires no API key. Surfaces only the PUBLIC open-core registry — operator-private mainnet addresses are never shown. |
| paybot_health_extendedB | Check extended facilitator health: status, version, uptime, timestamp, plus any extra fields the facilitator reports (e.g. relayer/gas/AML status). |
| paybot_set_spending_limitA | Set spending limits for a bot. Tightens the agent's own limits; the facilitator enforces the operator ceiling and may reject attempts to loosen beyond policy. |
| paybot_commission_inspectB | Inspect commission for transparency: aggregate summary (totals + rate) and a filterable, paginated ledger. |
| paybot_pool_createB | Create an in-process bot pool with an optional shared daily treasury. The pool lives for this MCP session; treasury accounting is in-memory and the facilitator remains authoritative. |
| paybot_pool_allocateB | Add a bot to a pool, and optionally make a payment as that bot through the shared treasury. |
| paybot_pool_revokeC | Remove a bot from a pool. |
| paybot_pool_statusB | Report a pool's remaining shared treasury and per-bot local spend/transaction counters (in-process projection; facilitator is authoritative). |
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 12 tools
Most tools target distinct resources: bot-level operations (balance, pay, history, register, set_spending_limit) are clearly separated from pool operations (pool_create, pool_allocate, pool_status, pool_revoke). Minor potential overlap between paybot_history and paybot_commission_inspect (both surface ledger-like data), and paybot_pool_allocate includes an optional payment that touches paybot_pay's domain, but descriptions make boundaries clear enough.
All tools share the paybot_ prefix and use snake_case throughout. There is a mild inconsistency in ordering: some are verb_noun (list_networks_and_tokens, set_spending_limit, pool_create), while others are bare nouns (balance, pay, history, register, health_extended), but the convention remains predictable and readable.
12 tools is well-scoped for a payment bot server covering registration, payments, limits, history, commissions, health, and pool management. Each tool appears to earn its place with no obvious redundancy or padding.
Core lifecycle is covered: register, pay, check balance, view history, set limits, inspect commissions, and manage pools. Gaps include no bot deregistration/unregister (pool_revoke only removes from a pool) and no dedicated bot detail/profile lookup beyond balance, but these are minor and workable.