Wallet MCP Server
Enables Claude and Codex to discover and execute paid APIs via a credit balance, handling registry search, top-up, and execution.
README
Wallet
One API for everything your agent needs.
Wallet is a skill and MCP bridge for Claude and Codex. It notices when an external capability can improve the user's current task, searches a live registry, explains the useful outcome and USD price, and uses the chosen service from one card-funded dollar balance.
Public product: https://wallet.pact.sh
Install once
- Create a Wallet at
https://wallet.pact.sh/wallet. - Choose Create pairing code.
- Install and claim the ten-minute code:
npm install --global git+https://github.com/learners-superpumped/api-mcp-pass.git
api-mcp-pass install --server https://wallet.pact.sh --host all --pair ABCD-EF12
The installer:
- Connects the installed agent to the user's existing web Wallet.
- Stores a separate agent token in
~/.wallet-pact/config.jsonwith mode0600. - Installs the proactive Wallet trigger skill for Claude and Codex.
- Adds a local stdio MCP bridge. The Wallet token is never copied into chat or MCP configuration.
Installing without --pair remains available for machine-only setup and creates a new zero-balance Wallet.
The user flow
A user asks an ordinary question such as: “Find recent Reddit complaints about AI coding agents and summarize the recurring problems.”
- The Wallet skill recognizes that a live social-search API can materially improve the answer.
wallet_discoversearches the registry and recommends the best API with its input contract, expected result, and USD price.- If the Wallet is empty,
wallet_top_upreturns a Stripe Checkout link. The agent preserves the original task. - After card payment, the funded dollar amount appears in the same Wallet and the agent resumes the task.
- Wallet funds the user's managed payment address for that call, then
wallet_executesigns and pays the selected x402 or MPP provider from that user-specific address. - A usable success captures the disclosed dollar amount. A confirmed provider failure captures nothing, releases the reservation, and returns compatible alternatives.
The current registry contains 37,529 uniquely addressable machine-readable operations across 1,969 services: 395 from six provider OpenAPI documents, 35,934 normalized x402 contracts from 1,832 Agentic Market services, and 1,200 unique MPP contracts from 137 services in the official mpp.dev catalog. Of those directory contracts, 35,326 x402 operations and 846 MPP operations publish a bounded price on an enabled network and are executable through the same Wallet gateway. HTTPS, method, price, currency, network, and maximum-spend checks fail closed; unsupported records remain discoverable but cannot spend credits.
Credits
- One-time card funding: enter any amount from $5 to $1,000.
- Automatic recharge: choose a dollar balance threshold and a $5 to $500 recharge amount, then explicitly authorize off-session card charges. A failed charge adds nothing and pauses the feature.
- Public prices and balances are denominated in USD. The internal cent/atomic ledger remains closed-loop and cannot be withdrawn or transferred.
- Every Wallet has a distinct encrypted EVM signer stored in SQLite. Its public address is shown on the dashboard and is used on both Base x402 and Tempo MPP calls.
- Fixed-price calls show their exact price. Dynamic-price calls reserve the published maximum and capture only the amount verified in provider payment metadata.
Product surfaces
- API explorer:
https://wallet.pact.sh/apis - Wallet dashboard:
https://wallet.pact.sh/wallet - Rewards and social verification:
https://wallet.pact.sh/wallet#rewards(the legacy/rewardsroute remains available) - The dashboard shows the user's provider-payment address, custom card funding, automatic recharge controls, current dollar balance, successful calls, a combined funding and usage ledger, and connected reward profiles.
- Stripe Checkout supports user-entered one-time amounts. Automatic recharge saves the card during its first paid Checkout and charges only after the chosen threshold is crossed.
Agent interfaces
- Registry:
GET /v1/registry - Task discovery:
POST /v1/discover - Wallet:
POST /v1/wallets,GET /v1/wallets/:id - Web Wallet:
POST /v1/web/email/start,POST /v1/web/email/verify,GET /v1/me - Agent pairing:
POST /v1/web/pairings,POST /v1/pairings/claim - Card funding:
POST /v1/checkout - Disable automatic recharge:
POST /v1/auto-recharge/disable - Billing portal:
POST /v1/billing/portal - Execution:
POST /v1/executions - Agent guide:
GET /agent.md - OpenAPI:
GET /openapi.json - MCP manifest:
GET /.well-known/mcp.json - MCP transport:
POST /mcp
Pact Agent OAuth
Wallet is the authorization server for the unified Pact Agent start flow. The default registered client is pact-agent, with the single exact callback https://agent.pact.sh/oauth/callback. Production must set a 32-character-or-longer PASS_OAUTH_PACT_AGENT_CLIENT_SECRET; alternate exact callbacks can be supplied as a comma-separated PASS_OAUTH_PACT_AGENT_REDIRECT_URIS allowlist.
Pact Agent starts authorization with GET /oauth/authorize and these required query parameters: response_type=code, client_id, exact redirect_uri, scope, unpredictable state, code_challenge, and code_challenge_method=S256. A signed-out browser is returned only to the local /wallet email signup/sign-in UI, then resumes the same server-held, HttpOnly-cookie-bound request. Production session and authorization-transaction cookies use the __Host- prefix, Secure, Path=/, and no Domain, so a sibling *.pact.sh origin cannot toss a Wallet cookie. A signed-in user sees explicit consent. Approval redirects to the registered callback with code and the unchanged state.
The Pact Agent server exchanges that one-time 60-second code using an HTTP Basic client credential and either an OAuth form body or JSON body:
POST /oauth/token
Authorization: Basic base64(pact-agent:CLIENT_SECRET)
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=oauth_code_...&redirect_uri=https%3A%2F%2Fagent.pact.sh%2Foauth%2Fcallback&code_verifier=...
{
"access_token": "wallet_oauth_...",
"token_type": "Bearer",
"expires_in": 2592000,
"scope": "wallet:read wallet:reserve wallet:checkout",
"sub": "wallet_..."
}
The access token is a separately digested, revocable grant. It is never an existing full wallet_sk token, and the OAuth response and scoped Wallet reads omit email and social identity. wallet:read authorizes GET /v1/me and the subject's GET /v1/wallets/:id; wallet:checkout authorizes POST /v1/checkout; wallet:reserve authorizes subject-bound reservation, debit settlement, and release. A reservation may declare a bounded max_credit_atomic ceiling so a verified Society, AgentPump, or Playground payout can use the same activity, but the OAuth bearer can never apply a positive credit settlement. Crediting verified service proceeds requires Pact Agent's separate server credential, so a self-asserted receipt cannot mint Wallet balance. Revoke the access token with authenticated POST /oauth/revoke and body token=wallet_oauth_....
Provider dispatch is idempotent. Before dispatch, Wallet checks the user's address on the selected chain and transfers only the deficit needed for the provider's published maximum plus the Tempo fee buffer. The transfer and encrypted signer are persisted in SQLite. Credits are reserved before money moves, captured after a verified success, and released on a confirmed failure. If a process stops during funding or after provider payment, or dynamic price metadata cannot be verified, the reservation remains locked for reconciliation instead of risking a duplicate payment or an incorrect charge. A Pact that reaches CANCELLED with no deposits or payouts is the one safe automatic recovery case: the provider could not have been dispatched, so Wallet releases the reservation without retrying payment.
Local verification
npm ci
npm test
The normal suite uses fixture providers and an isolated Pact 0.3.3 contract fixture. It validates per-call Pact settlement and refund without calling production or spending AgentCash funds.
An explicitly budgeted release canary spends one x402 and one MPP provider call from the configured AgentCash wallet:
AGENTCASH_LIVE=1 npm run test:sandbox
Production Wallet uses Pact 0.3.3 at https://api.pact.sh as an external API for every paid execution. Wallet deploys and serves discovery, signup, billing, and installation independently; immediately before provider dispatch it verifies Pact readiness and access, funds a dedicated Pact, settles it after a usable result, and completes a unanimous refund before releasing credits after a confirmed provider failure.
See deployment, verification, user scenarios, design QA, and security.
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。