Compatible with x402 V1/V2 + Stripe MPP — protocol-agnostic spend controls.
agentpay-mcp is the human-first trust and policy layer above commodity execution rails (x402, ACP, UCP). OWS-compatible trust layer -- works on top of MoonPay Open Wallet Standard. Protocol-agnostic trust layer -- works with x402 AND Stripe MPP. While x402 settles $600M annualized — with AI agents driving 40% of protocol activity (March 2026) — the missing piece isn't payment execution. It's governance: who approved it, how much can be spent, and what happens when the agent tries to exceed its budget. That's what agentpay-mcp provides.
ACP handles what agents SELL. agentpay-mcp handles what agents BUY. ACP (Agent Commerce Protocol) enables agents to list services, negotiate, and receive payments. agentpay-mcp is the complementary layer — controlling what agents spend when consuming paid APIs, tools, and services. Different problems, compatible solutions.
When your agent hits HTTP 402 Payment Required, it needs to pay and retry — with your approval, within limits you set. AgentPay MCP is a Model Context Protocol server that gives Claude, Cursor, and any MCP-compatible agent a payment wallet with hard spend caps, human-approval mode, and a full on-chain audit trail.
The MCP ecosystem now has 97M+ monthly downloads and 10,000+ active servers — agentpay-mcp is the only MCP-native full payment execution layer.
✅ Integrated into NVIDIA/NeMo-Agent-Toolkit-Examples (PR #17 merged) — payment infrastructure for NVIDIA's official agent toolkit.
📌 x402 ecosystem listing context is tracked in docs/x402-ecosystem-submission.md.
agentpay-mcp is built for three buyer personas who all share the same problem: autonomous agents spending money without controls.
Persona | Problem | What They Use agentpay-mcp For |
FinOps Practitioners (Fortune 500 AI spend owners) | 98% of FinOps teams now manage AI spend (FinOps Foundation 2026) — but no governance layer exists for autonomous agents | Cost center attribution, per-agent budget caps, CFO-ready spend dashboards, policy-as-code enforcement |
Platform Engineers (MCP / agent framework builders) | Agents call paid APIs at runtime with no native spend controls in x402, Stripe MPP, or MCP protocol | Drop-in spend governance middleware: daily caps, kill switches, per-task limits, audit trails |
Enterprise Compliance Teams (EU AI Act, SOC 2, internal audit) | EU AI Act Article 14 (enforced Aug 2, 2026) requires runtime human oversight and decision-time enforcement for autonomous agents | Human-approval queues, runtime kill switches, full on-chain audit trail for compliance evidence |
FinOps teams: agentpay-mcp is the first governance layer designed for your workflows — not just for developers. Budget caps, approval thresholds, and cost attribution that slot into your existing FinOps tooling.
Related MCP server: 402-mcp
McKinsey's 2026 AI Trust Maturity Survey quantifies what builders already feel: agent capability has outpaced agent governance.
Finding | Stat |
Enterprises that formally approve agents before deployment | 14.4% |
Enterprises reporting at least one agent security incident | 88% |
Enterprises confident in agent IAM for payments | 18% |
The trust gap is the deployment gap. Enterprises aren't saying agents don't work — they're saying the oversight infrastructure (approval workflows, spending guardrails, identity verification, audit trails) hasn't kept pace.
AgentPay MCP addresses this directly:
Human-approval mode — transactions above your threshold require explicit human confirmation before executing
On-chain spend caps — enforced by smart contract, not application code. The agent cannot override them.
Full audit trail — every payment attempt logged with merchant, amount, timestamp, approval status
Fail-closed — any policy engine error produces rejection, never approval
Non-custodial — private keys never leave the local machine
When 88% of enterprises have had an agent security incident, "trust by default" is not a viable architecture. AgentPay MCP is built for "verify, then trust" — which is the only model that scales.
The Model Context Protocol gives agents access to powerful tools — but the protocol itself has no built-in mechanism for controlling what those tools cost. This isn't a theoretical gap. WorkOS's 2026 guide to MCP security explicitly identifies rate limiting, cost attribution, and per-call spend caps as unsolved problems at the MCP protocol level. Every MCP server can charge. No MCP client enforces budgets.
The result: an agent with access to 10 MCP servers can accumulate unbounded costs across sessions, with no standard way to attribute spend per tool, cap exposure per call, or halt runaway loops before they drain a wallet.
AgentPay MCP closes this gap at the infrastructure layer:
MCP Cost Governance Gap | AgentPay MCP Solution |
No per-call spend caps in the MCP spec | On-chain per-transaction caps — enforced by smart contract, not application logic |
No cost attribution across MCP servers | Full transaction history with merchant, amount, timestamp, and tool context per call |
No rate limiting for paid tool invocations | Daily aggregate spend limits — hard ceiling regardless of how many tools or sessions run |
No human oversight mechanism in the protocol | Human-in-the-loop approval — transactions above threshold queue for explicit human review |
No simulation/dry-run for cost estimation | Simulation mode — preview transaction cost and recipient before committing funds |
If you're building agents that interact with paid APIs, MCP spend limits and MCP cost governance aren't optional — they're the difference between a demo and a production deployment. AgentPay MCP is the open-source reference implementation for solving this at the protocol's edge.
AgentPay MCP is built for enterprise MCP deployments where supply chain security matters.
Zero LiteLLM dependency. No direct or transitive dependency on LiteLLM or any heavyweight LLM routing layer. When LiteLLM versions 1.82.7-1.82.8 were compromised on PyPI (March 2026), AgentPay MCP users were unaffected.
Auditable, minimal dependency tree. The server runs on viem, @modelcontextprotocol/sdk, and a small set of auditable npm packages. No PyPI. No Python runtime required.
Enterprise trust signal. Integrated into NVIDIA's official NeMo Agent Toolkit Examples (PR #17, merged). NVIDIA's review process validated the security posture before merge.
Non-custodial architecture. Private keys never leave the local machine. On-chain spend caps enforce limits even if the agent or its key is compromised.
Vercel deployment hardening. If you deploy AI agents on Vercel, review the Vercel deployment hardening checklist before reconnecting paid tools after any OAuth, dashboard, CI, or environment-variable exposure.
x402 scanner readiness. For paid API demos that need scanner-readable x402 support, use the x402 scanner-readiness recipe.
x402 Bazaar observability. For paid MCP tools entering searchable Bazaar catalogs, use the x402 Bazaar observability recipe to cover WithBazaar search metadata, unified auth, and EXTENSION-RESPONSES readback.
x402 batch-settlement channels. For repeat paid MCP calls that use deposit, voucher, refund, and claim flows, use the x402 batch-settlement channel recipe to keep channel storage, voucher caps, recovery, and off-chain settlement audit trails production-safe.
x402 multi-SDK batch-settlement parity. For providers testing x402 TypeScript and Go batch-settlement clients, use the multi-SDK batch-settlement parity recipe to prove shared channel state, phased e2e results, signer separation, refund/recovery visibility, and proof bundle shape.
x402 TVM readiness. For TVM/TON exact-payment offers from emerging x402 examples, use the x402 TVM readiness note to confirm unsupported TVM requirements fail closed until deliberate signing, gas, jetton, and settlement support exists.
x402 MCP funding UX. For hosted fund-link and managed-wallet comparisons, use the x402 MCP funding UX benchmark to keep onboarding speed separate from approval gates, daily caps, auditability, and non-custodial controls.
Directory introspection readiness. For Glama, Smithery, and other MCP catalogs, use the directory introspection readiness note for verified npx, Docker, MCP name, and non-custodial metadata paths.
x402 v2.11 paid MCP compatibility. Use the compatibility proof for Payment-Signature, payment-response, mcp-session-id, CORS exposed headers, Streamable HTTP initialize order, receipt links, and Base Sepolia to Base mainnet cutover.
Directory-grade metadata proof. Use the registry/listing proof, docs/mcp-registry-listing.json, glama.json, smithery.yaml, and llms.txt for catalog crawlers and buyer agents.
Chain-neutral x402 gateway profile. Use the chain-neutral gateway profile proof, schema, and fixture to document supported networks, facilitator/settlement metadata, trial/refund policies, and directory manifests without leaking Base-only assumptions into non-EVM discovery.
Multi-ledger x402 receipt normalization. Use the multi-ledger receipt normalization proof, schema, and XRPL fixture to normalize ledger labels, assets, settlement targets, Payment-Signature, payment-response, verification status, non-custodial boundaries, and unsupported-ledger refusals before signing.
Wallet-action preflight profile. Use the wallet-action preflight profile and TRON fixture to require simulation, chain/resource caps, allowlists, recipient and amount confirmation, nonce guidance, and approval copy before irreversible sends, swaps, or resource purchases.
Machine-payment directory listing pack. Use the directory listing pack and listing JSON for MPP and paid-MCP directories without claiming unsupported non-EVM signing.
Five-tool x402 parity proof. Use the five-tool parity proof and machine-readable map to map search, check, fetch, wallet, and pay flows to AgentPay's local-signer, approval-gated controls.
Escrow and reputation boundary. Use the escrow/reputation boundary proof to keep x402 payment authorization separate from task escrow, identity, reputation, and work proof.
Paid MCP proxy and discovery readiness. Use the paid-proxy and discovery readiness pack plus listing JSON for Toolstem/Cinderwright-style proxy and directory submissions.
Dynamic paid MCP manifest drift. Use the dynamic manifest drift proof, schema, and Rug Munch fixtures to validate fresh .well-known/x402 snapshots, stale-metadata warnings, no-trial/pricing clarity, supported networks, and directory endpoint freshness before buyer agents sign.
Smithery paid MCP installation. Use the Smithery install proof and examples/smithery-paid-mcp-installation for Smithery CLI, Vercel AI SDK MCP, @smithery/api, approval gates, spend-limit defaults, and fresh x402 manifest checks. Do not claim live Smithery verification until the listing is verified.
x402-native vs Stripe-proxy MCP. For builders comparing AgentPay MCP with emerging Stripe-proxy MCP repos, use the x402-native vs Stripe-proxy note to keep approval gates, spend caps, audit rows, and non-custodial signing separate from proxy billing claims.
Hosted x402 proxy verification. Before an agent pays a hosted x402 MCP gateway, use the hosted x402 proxy buyer checklist to verify payment-required headers, non-zero payTo, network and asset allowlists, approval state, spend cap, audit correlation, and pooled-token lock-in.
Paid MCP discovery and budget response. For SettleGrid-style discovery, metering, and budget-platform comparisons, use the paid MCP discovery and budget response to separate directory discovery from x402 buyer authorization.
Buyer-flow parity for one-command x402 tools. For AgentScore Pay-style buyer CLI comparisons, use the AgentPay buyer-flow parity checklist to prove discover, check, dry-run, pay, spend caps, typed payment errors, quota envelopes, no-charge failures, idempotency, MCP exposure, and audit before signing.
Paid MCP gateway hardening. For create-mcpay-style Worker scaffolds, use the paid MCP gateway hardening checklist to test signup, challenge parsing, key minting, atomic billing, scope defaults, no-charge validation failures, and buyer audit rows.
Paid-provider health proof. For Voidly-style public provider health feeds, use the paid-provider health proof checklist to verify provider success rate, stale streaks, receipt state, x402 network, asset, payTo, and fail-closed routing before signing.
Paid-tool quality thresholds. For Strale-style scored catalogs, use the paid-tool quality thresholds proof to verify fresh score fields, stale-score warnings, provider-health snapshots, minimum-quality rejection, and approval gates before x402 signing.
Authorized cybersecurity scans. For AgentAegis-style paid security tools, use the authorized cybersecurity-scan payment profile to require target authorization, allowed-domain binding, per-target spend caps, scan-rate policy, approval prompts, and audit receipt language.
Post-quantum spend-envelope compatibility. For PQSafe-style buyer questions, use the post-quantum spend-envelope assessment to map spend limits, allowlists, x402 receipts, approval gates, and audit metadata without claiming ML-DSA implementation.
Payment-critical dependency pins. For x402 verifier and signing paths, AgentPay pins viem exactly at 2.48.7, enforces the same root override, and runs a clean-install smoke check before release. See the dependency pin policy.
WhatsApp and SMB agent controls. For channel-native paid agents, use the WhatsApp and SMB paid-agent controls recipe.
Channel-agent affiliate payout controls. For Axon-style affiliate and referral revenue shares, use the channel-agent affiliate controls spec to keep payout caps, per-contact approval, audit rows, and optional x402 settlement separate from paid tool spend approval.
x402 chain drift. AgentPay MCP tracks the x402 Foundation paywall-template baseline with viem 2.48.7 exactly, and fails closed for unmapped chains. For PaymentWrapper and paywall template changes, follow the x402 chain-drift compatibility note.
If your security team is auditing MCP server dependencies after the LiteLLM incident, npm ls on agentpay-mcp gives you a short, reviewable tree with zero Python supply chain exposure.
Google's Agent2Agent (A2A) protocol (v1.0.0) establishes how agents discover, authenticate, and collaborate across organizational boundaries. The spec is built around Agent Cards, security schemes, and human-in-the-loop task management — but it deliberately does not define spending governance at the protocol level.
agentpay-mcp fills that gap as a complementary governance layer. Here's how our controls map to A2A's architecture:
A2A Concept | What the Spec Defines | What agentpay-mcp Adds |
Agent Cards ( | Agents declare what they can do and how to authenticate | agentpay-mcp adds spend policy as a discoverable capability — daily caps, per-tx limits, approval thresholds |
Human-in-the-loop ( | Tasks can pause for human input mid-execution | agentpay-mcp enforces this for payments: transactions above a configurable threshold queue for explicit human approval before executing |
Security schemes (OAuth, API keys, mTLS) | Authentication between agents | agentpay-mcp provides the authorization complement — not just "is this agent allowed to connect?" but "is this agent allowed to spend $X?" |
Extensions (spec §4.6) | Agents can expose additional structured data beyond core A2A | Spend caps, approval history, and transaction receipts can be surfaced as extension data in A2A task metadata |
Opaque execution (guiding principle) | Agents collaborate without exposing internals | agentpay-mcp preserves opacity — the paying agent's private key and internal budget logic never leave the local machine |
When two A2A-compliant agents collaborate on a task that involves paid API calls:
Discovery — The calling agent reads the remote agent's Agent Card (A2A spec)
Authentication — Mutual authentication via declared security schemes (A2A spec)
Spend governance — agentpay-mcp enforces budget caps, logs transactions, and gates high-value payments on human approval (agentpay-mcp layer)
Audit — Full on-chain transaction trail provides compliance evidence independent of either agent's internal state
This positions agentpay-mcp as the spend governance layer for A2A-compliant agent ecosystems — complementing the protocol's identity and task management with the financial controls enterprises require before deploying autonomous agents.
Note: The A2A v1.0.0 spec does not define a trust scoring or trust signals mechanism at the protocol level. agentpay-mcp's governance controls (spend caps, human approval, on-chain audit trails) are designed to be compatible with future trust-related extensions as the A2A ecosystem evolves.
AgentPay MCP is designed to be discovered and used by AI agents. Compatible with:
claude-mem - Payment state (transaction history, budgets, session tokens) persists as agent memory across sessions via claude-mem's observation layer
AgentSkills - Installable as a cross-framework skill in any AgentSkills-compatible harness (Claude Code, Cursor, Gemini CLI, Antigravity)
Chrome DevTools MCP - Pairs as the payment layer for browser-native agents
Add to any MCP-compatible harness config:
{
"mcpServers": {
"agentpay": {
"command": "npx",
"args": ["agentpay-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0x...",
"AGENT_WALLET_ADDRESS": "0x..."
}
}
}
}Works with Claude Code, Cursor, Gemini CLI, OpenClaw, Windsurf, and any MCP client.
Agent calls a paid API
│
▼
HTTP 402 ←── "Payment required: 0.50 USDC on Base"
│
▼
AgentPay MCP evaluates your policy:
• Is 0.50 USDC under your per-tx cap? ($5 limit → ✅)
• Is this recipient allowlisted? (api.example.com → ✅)
• Require human approval? (under $1 threshold → auto)
│
▼
Payment sent → API retried with payment proof → 200 OK
│
▼
Agent gets the data. Full tx on basescan.org.Both projects enable agent payments. They solve different problems at different layers.
Capability | agentpay-mcp | x402-mcp (Coinbase) |
Payment execution | ✅ x402 + Stripe MPP | ✅ x402 only |
On-chain spend caps | ✅ Smart contract enforced | ❌ No caps |
Per-session budget limits | ✅ Hard session ceiling | ❌ Unlimited per session |
Daily aggregate limits | ✅ Configurable daily max | ❌ No daily limits |
Human-in-the-loop approval | ✅ Threshold-based queue | ❌ Fully autonomous only |
Transaction simulation | ✅ Dry-run before commit | ❌ Execute or nothing |
Multi-protocol support | ✅ x402 V1/V2 + Stripe MPP | ⚠️ x402 only |
OWS wallet compatibility | ✅ MoonPay Open Wallet Standard | ❌ Coinbase wallet only |
Audit trail | ✅ Full tx history with merchant, amount, status | ⚠️ Basic tx log |
FinOps integration | ✅ Cost attribution per session/agent | ❌ Not available |
Fail-closed policy engine | ✅ Errors → rejection, never approval | ❌ No policy engine |
Non-custodial | ✅ Keys never leave local machine | ✅ Keys never leave local machine |
Enterprise trust signal | ✅ NVIDIA NeMo Toolkit PR #17 merged | — |
When to use x402-mcp: You want the simplest possible x402 payment integration with no governance requirements. Your agent operates with unlimited budget authority.
When to use agentpay-mcp: You need spend controls, budget enforcement, human approval workflows, or multi-protocol support. Your agents operate against real enterprise budgets where runaway spending is a deployment blocker.
x402-mcp adds payments to your agent. agentpay-mcp adds governed payments — spend caps, session limits, human approval, and audit trails that enterprises require before deploying agents against production budgets.
Public MCP payment repos are starting to use x402 plus Stripe Agent wording for discovery. Treat that as a market signal, not as proof that every proxy has shipped complete spend control.
What is the main difference?
AgentPay MCP keeps the payment decision inside the agent's policy boundary. The agent requests x402_pay, AgentPay checks approval state and spend policy before signing, and the audit trail records the tool, amount, merchant, receipt, and policy result. A Stripe-proxy pattern usually puts a payment or billing proxy in front of a downstream service.
Why not use a proxy for every paid MCP call?
A proxy can help with billing and account aggregation. It does not automatically answer who approved the spend, whether the agent stayed inside its task budget, or whether a signature was blocked before policy approval. AgentPay MCP handles those controls before payment execution.
What proof can a directory or buyer check today?
npm: agentpay-mcp@4.1.9 or newer
Glama: https://glama.ai/mcp/servers/up2itnow0822/claw-pay-mcp
Catalog metadata: glama.json and smithery.yaml
Install paths: npx and Docker
Introspection: 27 MCP tools including x402_pay, check_budget, set_spend_policy, and otel_evaluate_spend
How does this compare with Lightning Wallet MCP?
Lightning Wallet MCP is a Bitcoin wallet MCP with Glama-facing badge work and x402 fallback positioning. AgentPay MCP is focused on x402 payment-tool governance: approval gates, hard spend caps, non-custodial local signing, directory metadata, and audit rows tied to paid tool calls.
For the full checklist, see x402-native AgentPay MCP vs Stripe-proxy MCP patterns.
For hosted paid-MCP gateways, use Hosted x402 proxy buyer verification checklist before signing. It checks payment-required headers, payTo, chain, asset, spend cap, approval gate, audit log, and pooled-token lock-in.
For one-command buyer CLI comparisons, use AgentPay buyer-flow parity checklist. It turns discover, check, dry-run, pay, spend cap, typed payment errors, quota envelopes, no-charge failures, idempotency, MCP exposure, and audit into a fail-closed fixture. For paid Worker templates, use Paid MCP gateway hardening checklist before treating a scaffold as production-ready.
npm install -g agentpay-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"agentpay": {
"command": "npx",
"args": ["agentpay-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0x...",
"AGENT_WALLET_ADDRESS": "0x...",
"CHAIN_ID": "8453"
}
}
}
}Add to .cursor/mcp.json or ~/.cursor/mcp.json:
{
"mcpServers": {
"agentpay": {
"command": "npx",
"args": ["agentpay-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0x...",
"AGENT_WALLET_ADDRESS": "0x...",
"CHAIN_ID": "8453"
}
}
}
}Once running, tell your agent:
Set my spend policy: $1 per transaction, $10 per day, only send to allowlisted addresses.Or call set_spend_policy directly:
{
"tool": "set_spend_policy",
"arguments": {
"perTxCapEth": "0.0004",
"dailyLimitEth": "0.004",
"allowedRecipients": ["0xapi-provider-address..."]
}
}Now your agent can pay for APIs — and can't spend more than $1 at a time or $10 in a day, regardless of what it's instructed to do.
By default, transactions above your auto-approve threshold queue for human review. The agent cannot bypass this.
$0.50 USDC request → under $1 threshold → auto-approved → paid → result returned
$5.00 USDC request → over $1 threshold → queued → you get notified → approve or rejectTo approve a queued payment:
{
"tool": "queue_approval",
"arguments": {
"action": "approve",
"tx_id": "0x..."
}
}To reject it:
{
"tool": "queue_approval",
"arguments": {
"action": "cancel",
"tx_id": "0x..."
}
}The agent sees the outcome and decides what to do next (use cached data, ask user, abort).
What it does: Finds the right paid API for a data need, pays once, caches the result.
When to use it: Your agent needs data (market data, enrichment, geocoding) and you want it to handle payment automatically rather than failing with a 402.
Agent: "I need current options flow data for AAPL"
│
├─ Tries free sources → insufficient data
├─ Finds paid API → gets 402 for $0.25 USDC
├─ Checks: $0.25 < $1 cap → auto-approved
├─ Pays with x402_pay → gets data
├─ Caches result at ~/.clawpowers/state/market:AAPL:options
└─ Returns data + payment receiptTools used: x402_pay, check_spend_limit, get_transaction_history
Example exchange:
User: Get me the options flow for AAPL for the last 7 days.
Agent: Checking free sources... insufficient. Found paid API at data.example.com.
Cost: $0.25 USDC (under your $1 auto-approve cap). Paying now.
[x402_pay → 200 OK, paid 0.25 USDC, tx: 0xabc...]
Here's the options flow data: [results]
Total cost today: $0.25 of your $10 daily budget.What it does: Gathers from free sources first, fills gaps with paid data, compiles a structured output.
When to use it: You need a comprehensive research report and want the agent to spend money only where free data is genuinely insufficient.
Agent: "Research competitive landscape for real-time flight tracking APIs"
│
├─ Scrapes free sources (GitHub, HN, docs) → baseline data
├─ Identifies gaps: pricing data, SLA guarantees, enterprise contacts
├─ Proposes paid lookups totaling $2.75 USDC → presents for approval
├─ Human approves
├─ Pays for Apollo contact enrichment ($1.50) + Crunchbase data ($1.25)
└─ Compiles: free data + paid data → structured reportTools used: x402_pay, x402_session_start, x402_session_fetch, check_budget
Example exchange:
User: Research the real-time flight tracking API market. Budget up to $5.
Agent: Starting with free sources... [scrapes 12 sources, builds baseline]
Gaps identified:
- Vendor pricing (not public for 3 of 5 vendors)
- Contact info for enterprise sales at FlightAware
- Recent funding data for two startups
To fill these I'd spend ~$2.75 USDC:
- Apollo contact enrichment: $1.50
- Crunchbase firmographics: $1.25
Approve? (y/n)
User: y
Agent: [pays, fetches, compiles]
Report ready. Spent $2.75 of your $5 budget. [structured report attached]What it does: Completes real tasks end-to-end, paying for whatever services are needed along the way.
When to use it: You want an agent that can actually finish work — book a call, run an enrichment pipeline, deploy something — not just research it.
Agent: "Enrich this list of 50 leads and add to CRM"
│
├─ Processes first 10 free (from existing data)
├─ Remaining 40 need enrichment → $0.10/contact = $4.00 USDC
├─ Presents plan: 40 contacts × $0.10 = $4.00 total → user approves
├─ Runs enrichment in batches of 10 (staying under per-tx cap)
├─ Writes enriched data to CRM via API
└─ Reports: 50 leads enriched, $4.00 spent, 47 successfulTools used: x402_pay, x402_session_start, set_spend_policy, get_transaction_history
Production agent deployments need spending governance that satisfies enterprise FinOps requirements. These templates show common patterns for controlling agent spend at the infrastructure layer.
// Marketing agent — $50/day cap, restricted to approved data vendors
{
"tool": "set_spend_policy",
"arguments": {
"perTxCapEth": "0.02",
"dailyLimitEth": "0.02",
"allowedRecipients": ["0xmarketingVendor1...", "0xmarketingVendor2..."]
}
}
// Engineering agent — $200/day cap, broader vendor access
{
"tool": "set_spend_policy",
"arguments": {
"perTxCapEth": "0.04",
"dailyLimitEth": "0.08",
"allowedRecipients": ["0xcloudProvider...", "0xapiVendor...", "0xdataSource..."]
}
}Map your org's approval matrix to agent spending tiers:
$0 - $1 -> auto-approved (routine API calls)
$1 - $25 -> auto-approved with logging (standard tool usage)
$25 - $100 -> queued for team lead approval via queue_approval
$100+ -> queued for finance team approvalSet the auto-approve ceiling with set_spend_policy, and transactions above the per-tx cap automatically queue for human review. No code changes needed — the smart contract enforces it.
Pull real-time spend data for your FinOps tooling:
// Check remaining budget before starting expensive workflows
{ "tool": "check_budget", "arguments": {} }
// Returns: { "remaining": "142.50 USDC", "spent": "57.50 USDC", "limit": "200.00 USDC" }
// Pull transaction history for cost attribution
{ "tool": "get_transaction_history", "arguments": { "limit": 100 } }
// Each entry includes: merchant, amount, timestamp, tool context — ready for FinOps importThese patterns work with any FinOps platform (CloudHealth, Kubecost, Apptio) — export transaction history via the MCP tool and feed it into your existing cost attribution pipeline.
# Required
AGENT_PRIVATE_KEY=0x... # Agent hot wallet key (0x-prefixed hex)
AGENT_WALLET_ADDRESS=0x... # Deployed AgentAccountV2 contract address
# Optional
CHAIN_ID=8453 # 8453 = Base Mainnet (default, recommended)
RPC_URL=https://mainnet.base.org # Custom RPC (Alchemy/Infura recommended for production)
SESSION_TTL_SECONDS=3600 # x402 session lifetime (default: 1 hour)
FACTORY_ADDRESS=0x... # For deploy_wallet and create_escrow
NFT_CONTRACT_ADDRESS=0x... # For deploy_walletTool | What It Does |
| Fetch a URL, automatically pay 402, retry — the core use case |
| Pay once, get reusable session token for a base URL |
| Make calls within an active session (no new payment) |
| Inspect active sessions and TTL |
| Explicitly close a session |
Tool | What It Does |
| Address, balances, spend limits, queue depth |
| Send ETH or ERC-20 via the AgentAccountV2 contract |
| Remaining spend limit for current period |
| Configure daily limits, per-tx caps, recipient allowlists |
| Query on-chain remaining budget |
| Approve or cancel a queued transaction |
| On-chain event logs with filtering |
| Deploy a new AgentAccountV2 smart contract wallet |
Tool | What It Does |
| Token address + decimals by symbol and chain |
| Register a custom ERC-20 in the token registry |
| All registered tokens for a chain |
| Send any registry token (resolves address + decimals automatically) |
| Token balances across one or more tokens |
Tool | What It Does |
| Uniswap V3 swap on Base, Arbitrum, Optimism, or Polygon |
| CCTP V2 cross-chain USDC bridge (10 EVM chains, ~12s) |
Tool | What It Does |
| ERC-8004 on-chain identity verification |
| On-chain reputation score and history |
| Mutual-stake USDC escrow — both parties lock collateral |
x402_pay — The Core Tool// Request
{
"tool": "x402_pay",
"arguments": {
"url": "https://api.example.com/premium-data",
"max_payment_eth": "0.0002"
}
}
// Response
{ "status": 200, "body": "{ ... }" }If the cost exceeds max_payment_eth, the tool returns an error before paying — no surprise charges.
x402_session_start — Pay Once for Multiple Calls// Request
{
"tool": "x402_session_start",
"arguments": {
"endpoint": "https://api.example.com/",
"ttl_seconds": 3600,
"label": "market-data-session"
}
}
// Response
{ "session_id": "sess_abc123", "token": "eyJ...", "expires_at": 1741000000 }// Subsequent calls — no new payment
{
"tool": "x402_session_fetch",
"arguments": {
"url": "https://api.example.com/stocks/AAPL",
"session_id": "sess_abc123"
}
}check_budget — Know Before You Loop// Request — check before starting an expensive loop
{ "tool": "check_budget", "arguments": {} }
// Response
{
"remaining": "7.50 USDC",
"spent": "2.50 USDC",
"limit": "10.00 USDC",
"periodEnds": "2026-03-24T00:00:00Z"
}Chain | Chain ID | Recommended For |
Base Mainnet | 8453 | Everything — lowest gas, most x402 activity |
Arbitrum One | 42161 | High-throughput swaps |
Optimism | 10 | Low-cost transfers |
Polygon | 137 | High-frequency micro-payments |
Ethereum Mainnet | 1 | Identity, large settlements |
Avalanche | 43114 | Bridge, transfers |
Linea / Unichain / Sonic / Worldchain | various | Bridge, transfers |
Base Sepolia | 84532 | Testing |
Non-custodial: The agent signs all transactions locally with its private key. No third party holds or validates keys.
On-chain enforcement:
Per-transaction caps — over-cap transactions queue for human approval via queue_approval
Daily period limits — aggregate spending enforced by the AgentAccountV2 smart contract
Recipient allowlists — restrict which addresses the agent can send to
Role separation:
The agent's signing key (AGENT_PRIVATE_KEY) can only transact within limits set by the wallet owner. Even if the agent's key is leaked or the agent is compromised, an attacker can only spend up to the configured cap before the next reset.
x402 sessions:
Session tokens are ECDSA-signed claims. Any x402 V2 server can independently verify them — no central session store required.
Minimal dependency footprint:
AgentPay MCP has zero LiteLLM dependency. The entire server runs on viem (Ethereum client), @modelcontextprotocol/sdk, and a handful of auditable packages — no heavyweight LLM routing layers in the dependency tree. This matters: on March 24, 2026, LiteLLM versions 1.82.7 and 1.82.8 on PyPI were confirmed compromised in a supply chain attack targeting AI agent infrastructure. Any MCP server that depends on LiteLLM (directly or transitively) was exposed. AgentPay MCP was not — because payment infrastructure should have the smallest possible attack surface.
The agent payment landscape just split: Coinbase's x402 (open, permissionless, on-chain) vs Stripe's MPP (permissioned, Tempo-based, USDC). Developers building production agents face a choice — or they use agentpay-mcp, which already sits above both.
agentpay-mcp is protocol-agnostic by design:
Payment Rail | Status | How agentpay-mcp Works With It |
x402 (Coinbase) | ✅ Supported | Native x402 V1/V2 payment execution with on-chain spend caps |
Stripe MPP | ✅ Compatible | MPP-compatible settlement layer separation — agentpay-mcp governs spend policy above MPP's settlement |
Future rails | ✅ Ready | Neutral governance architecture — new rails plug in without code changes |
Why this matters: Neither x402 nor MPP ships spend governance. x402 wallets are unlimited by default. MPP offers human-set dashboard limits but no programmatic per-session or per-task enforcement. agentpay-mcp provides the budget circuit-breaker, approval workflows, and audit trail above both — regardless of which rail settles the transaction.
This isn't a wrapper around one protocol. It's a governance layer with a deliberate separation between policy (who approved it, what's the budget, should a human review this) and settlement (which blockchain or payment network moves the money). That separation is what makes agentpay-mcp rail-neutral — and what positions it as the governance standard as the protocol war plays out.
AWS AgentCore provides enterprise-grade agent hosting with Cedar-based policy enforcement for access control. Cedar policies answer: "Is this agent allowed to call this API?" and "Can this agent access this resource?"
What Cedar does NOT provide: spend limits. There is no Cedar primitive for "this agent can spend at most $50 per session" or "halt the agent if cumulative spend exceeds $200 today." Access control and budget governance are different problems.
agentpay-mcp adds the budget circuit-breaker on top of AgentCore:
Layer | Who Handles It | What It Controls |
Access Control | AWS AgentCore (Cedar) | Which APIs the agent can call, which resources it can access |
Budget Governance | agentpay-mcp | How much the agent can spend per transaction, per session, and per day |
Human Oversight | agentpay-mcp | When autonomous operation pauses for human approval |
Audit Trail | Both (complementary) | Cedar logs access decisions; agentpay-mcp logs spend decisions with on-chain receipts |
Deployment pattern: AgentCore runs the agent with Cedar policies controlling tool access. agentpay-mcp runs as an MCP server within the agent's tool set, enforcing spend caps on every payment action. Cedar says "you may call this paid API." agentpay-mcp says "you may spend up to $5 on this call."
{
"mcpServers": {
"agentpay": {
"command": "npx",
"args": ["agentpay-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0x...",
"AGENT_WALLET_ADDRESS": "0x...",
"MAX_TRANSACTION_USDC": "5.00",
"DAILY_LIMIT_USDC": "50.00"
}
}
}
}For enterprises running agents on AgentCore: Cedar handles the "can it?" question. agentpay-mcp handles the "should it spend this much?" question. Together, they provide the access + budget governance stack that production agent deployments require.
The simplest way to think about it: ACP (Stripe) handles what agents SELL, agentpay-mcp handles what agents BUY.
Developers often ask: "Doesn't Stripe MCP already handle agent payments?" The answer is that they solve different problems at different layers:
Stripe MCP | agentpay-mcp | |
Direction of money | User pays merchant (through agent) | Agent pays API provider |
Use case | Checkout, subscriptions, invoicing | API access, tool payments, agent-to-agent commerce |
Settlement | Traditional card rails | On-chain (Base, EVM) or Stripe MPP |
Spend controls | Customer-side (cart + checkout) | Agent-side (on-chain caps, human approval, session limits) |
Protocol | ACP (Agent Commerce Protocol) | x402 (HTTP 402 Payment Required) |
Stripe MCP is a merchant tool — it helps businesses charge customers through agent interfaces. Think "buy this product" or "subscribe to that plan."
agentpay-mcp is an agent procurement tool — it lets agents pay for the APIs and tools they need to do their work. Think "access this premium data endpoint" or "use this compute resource."
Most production agents will need both layers: Stripe MCP for user-facing commerce, agentpay-mcp for the agent's own tool costs. They're complementary, not competing.
AgentPay MCP aligns with the emerging MCP security standards for 2026, including CoSAI (Coalition for Secure AI) threat categories and OAuth 2.1 requirements.
Security posture documentation: See docs/security-posture.md for the full compliance matrix covering:
CoSAI T9 (Financial Fraud) — On-chain spend caps, merchant allowlists, and human-approval gates mitigate unauthorized agent spending
CoSAI T10 (Identity Spoofing) — ERC-8004 agent identity verification + non-custodial key management prevent identity-based attacks
OAuth 2.1 + PKCE — MCP server authentication supports OAuth 2.1 with PKCE for enterprise SSO integration (Azure AD, Okta)
MCP Audit Logging — Every tool invocation logged with timestamp, parameters, outcome, and transaction hash (where applicable)
For enterprise security teams evaluating MCP servers: the security posture document provides the artifact your audit process needs.
┌─────────────────────────────────────────┐
│ AI Agent (Claude / Cursor / Windsurf) │
└────────────────┬────────────────────────┘
│ MCP (stdio / SSE)
┌────────────────▼────────────────────────┐
│ AgentPay MCP Server │
│ ┌────────────┐ ┌────────────────────┐ │
│ │ 23 Tools │ │ Session Manager │ │
│ └─────┬──────┘ └────────────────────┘ │
│ │ │
│ ┌─────▼──────────────────────────────┐ │
│ │ agentwallet-sdk v6.0.0 │ │
│ │ TokenRegistry SwapModule │ │
│ │ BridgeModule ERC8004Client │ │
│ └─────┬──────────────────────────────┘ │
└────────┼────────────────────────────────┘
│ viem + RPC
┌────────▼────────────────────────────────┐
│ AgentAccountV2 Smart Contract │
│ SpendingPolicy · Tx Queue │
│ (12 chains — Base, ETH, ARB, OP, ...) │
└─────────────────────────────────────────┘Transport: stdio by default (Claude Desktop, Cursor, Windsurf). SSE available for remote deployments.
git clone https://github.com/up2itnow0822/agentpay-mcp
cd agentpay-mcp
npm install
npm run build
npm testPatent Pending — USPTO provisional application filed March 2026: "Non-Custodial Multi-Chain Financial Infrastructure System for Autonomous AI Agents."
We support the open x402 standard. Our filing is defensive — to prevent hostile monopolization of open payment rails, not to restrict builders using open standards.
agentpay-mcp is fully compatible with Vercel's x402-mcp package. If you're using Vercel's paidTool() to monetize MCP tools, agentpay-mcp works as the client-side payment layer — your agent pays x402 invoices from paidTool() endpoints automatically via x402_pay.
What agentpay-mcp adds on top of x402-mcp:
Multi-rail payments — route through x402 (USDC on-chain) or Stripe Machine Payments Protocol (fiat) depending on the merchant
Spend governance — per-tx caps, daily limits, and human-approval queues that paidTool() endpoints don't enforce client-side
Multi-chain x402 v2 — pay on Base, Solana, or Polygon (x402 v2 supports all three networks natively)
Use Vercel x402-mcp on the server side to monetize your tools. Use agentpay-mcp on the client side to pay for tools safely.
agentpay-mcp supports Circle Nanopayments as a settlement option for x402 v2 payments. Nanopayments enable gas-free sub-cent USDC transfers by batching small payments into single on-chain settlements.
How it works with agentpay-mcp:
Agent makes an x402 payment via x402_pay as normal
If the x402 v2 server supports Circle Nanopayments, settlement happens gas-free
Sub-cent payments ($0.001, $0.0001) become economically viable for per-call API pricing
Cross-chain support via Circle's Gateway — works on any EVM chain
This is especially useful for high-frequency agent workflows where gas costs would otherwise exceed the payment amount. See Circle's announcement for protocol details.
agentpay-mcp is built on the x402 HTTP payment standard, which has now processed 75M+ transactions on Base mainnet — primarily through Coinbase Agentic Wallets and developer integrations.
Cloudflare has added native x402 support to its Agents SDK and MCP server runtime, meaning any Cloudflare Worker-hosted agent can now make x402 payments natively. Google, Circle, and Stripe are all actively integrating x402 into their agent ecosystems.
agentpay-mcp is the open-source governance layer on top of this infrastructure: while x402 handles the payment protocol, agentpay-mcp adds the trust controls that production agents require — HITL approval queues, spend caps, recipient allowlists, and on-chain audit trails.
x402 Ecosystem | Status |
Base mainnet transactions | 75M+ |
Cloudflare Agents SDK | ✅ Native support |
Cloudflare MCP servers | ✅ Native support |
Coinbase Agentic Wallets | ✅ Primary client |
Google / Circle / Stripe | 🔄 Active integration |
agentpay-mcp governance layer | ✅ Open-source |
OpenAI has published a Delegated Payment Spec that defines how AI agents handle payments on behalf of users: a scoped token with an allowance cap, compatible with Stripe Scoped Payment Tokens (SPTs). This is the precursor architecture to native payment tooling in OpenAI's Agents SDK.
agentpay-mcp's spending cap model directly aligns with the Delegated Payment Spec pattern:
Delegated Payment Spec Concept | agentpay-mcp Implementation |
Scoped token — agent receives limited-scope credential |
|
Allowance cap — maximum the agent can spend |
|
Human approval — user delegates, then agent executes |
|
Audit trail — all delegated spend is logged |
|
Revocation — user can revoke delegation at any time | Spend policy updates are instant; wallet owner can freeze the agent key |
The core pattern is identical: human approves a budget → agent executes within that budget → all activity is auditable. The difference is settlement layer: OpenAI's spec targets Stripe SPTs (fiat rails), while agentpay-mcp settles on-chain (USDC/ETH on Base, Arbitrum, and 8 other EVM chains).
For developers building OpenAI Agents SDK workflows that need on-chain settlement or multi-rail payment execution, agentpay-mcp serves as the MCP payment tool that implements the Delegated Payment Spec pattern with on-chain enforcement rather than application-level trust.
{
"mcpServers": {
"agentpay": {
"command": "npx",
"args": ["agentpay-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0x...",
"AGENT_WALLET_ADDRESS": "0x..."
}
}
}
}Add this MCP server to any OpenAI Agents SDK workflow via MCP bridge. The agent gets x402_pay, check_budget, and set_spend_policy — the same scoped-token + allowance-cap pattern, enforced by smart contract.
agentpay-mcp complements Google's Agent2Agent Payment (AP2) protocol. AP2 — backed by 60+ organizations including Visa, Mastercard, and PayPal — handles agent payment authorization: verifying that a payment request is legitimate. agentpay-mcp operates at the governance layer above AP2, adding per-agent budget caps, daily spend limits, and human-approval thresholds that AP2 deliberately scopes as out-of-band. For enterprises deploying agents across multiple payment rails, agentpay-mcp provides the unified spend governance that no individual protocol covers.
Enforcement deadline: August 2, 2026. AI systems that execute or facilitate financial transactions are classified as high-risk under EU AI Act Annex III. High-risk classification requires:
✅ Human oversight mechanisms — mandatory human review and override capability
✅ Transparency and explainability — auditable transaction records
✅ Access controls — spend limits that cannot be bypassed by the agent
✅ Technical documentation — conformity assessment support
agentpay-mcp satisfies all four requirements out of the box:
Requirement | agentpay-mcp Feature |
Human oversight |
|
Audit trail |
|
Spend controls |
|
Scope restriction | Recipient allowlists — agent cannot send to unapproved addresses regardless of instructions |
European enterprises deploying agent systems that touch payments have ~150 days to implement compliant human oversight and audit controls. agentpay-mcp is the fastest path to EU AI Act compliance for MCP-compatible agent deployments.
Fines for non-compliance: Up to €35M or 7% of global annual revenue. Germany published its national enforcement bill in February 2026.
MIT © AI Agent Economy
Built by AI Agent Economy — infrastructure for production agent workflows.
Check whether a proposed payment amount is within the wallet's autonomous spend limits. Returns a clear yes/no with remaining budget details. Use this before send_payment to avoid surprise queuing.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_eth | Yes | Amount in ETH to check (e.g. "0.01") | |
| token | No | Token address. Omit for native ETH. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the return format ('clear yes/no with remaining budget details') and the practical consequence ('avoid surprise queuing'), but doesn't mention authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though 'check' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose and return value, the second provides crucial usage guidance. No wasted words, and the most important information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description does well by explaining the purpose, return format, and usage context. However, it could be more complete by explicitly stating this is a read-only operation (implied but not stated) and mentioning any authentication requirements. The connection to 'send_payment' is excellent contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (it mentions 'proposed payment amount' which aligns with 'amount_eth' but provides no additional syntax or format details). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('check') and resource ('proposed payment amount'), and distinguishes it from sibling tools by explicitly mentioning 'send_payment' as an alternative. It explains what the tool does (verifies if amount is within wallet's autonomous spend limits) and what it returns (yes/no with budget details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this before send_payment to avoid surprise queuing'), clearly positioning it as a prerequisite check. It distinguishes from the 'send_payment' sibling by explaining the sequential relationship and purpose (avoid queuing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a new AgentAccountV2 wallet via the factory contract. The wallet is deterministically addressed (CREATE2) and owned by an NFT. Returns the wallet address and deployment transaction hash. Requires FACTORY_ADDRESS and NFT_CONTRACT_ADDRESS env vars (or pass them as arguments).
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | NFT token ID that will own this wallet (e.g. "1") | |
| nft_contract_address | No | NFT contract address. Defaults to NFT_CONTRACT_ADDRESS env var. | |
| factory_address | No | Factory contract address. Defaults to FACTORY_ADDRESS env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the deterministic addressing (CREATE2), NFT ownership, return values (wallet address and transaction hash), and environment variable requirements. It doesn't mention potential side effects like gas costs or blockchain confirmation times, but covers the core operational behavior adequately for a deployment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and key characteristics, the second covers return values and configuration options. Every phrase adds value with zero redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment tool with no annotations and no output schema, the description provides good coverage: it explains what the tool does, how it works, what it returns, and configuration options. The main gap is the lack of explicit output format details (though 'wallet address and deployment transaction hash' gives a general idea), but given the tool's straightforward purpose, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mainly noting that factory_address and nft_contract_address can come from environment variables. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Deploy a new AgentAccountV2 wallet'), the mechanism ('via the factory contract'), and key characteristics ('deterministically addressed (CREATE2) and owned by an NFT'). It distinguishes this tool from sibling tools like 'check_spend_limit' or 'send_payment' by focusing on wallet creation rather than transaction management or querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to deploy a new wallet with specific ownership and addressing. It mentions environmental variable alternatives ('Requires FACTORY_ADDRESS and NFT_CONTRACT_ADDRESS env vars (or pass them as arguments)'), which helps guide parameter usage. However, it doesn't explicitly state when NOT to use it or compare it to specific sibling tools for similar functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the wallet's recent on-chain transaction history from event logs. Shows executions, queued transactions, approvals, cancellations, spend policy updates, and operator changes. Filter by event type or block range for targeted queries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default: 20, max: 100) | |
| from_block | No | Start block (decimal string). Defaults to 1000 blocks ago. | |
| to_block | No | End block (decimal string). Defaults to latest. | |
| event_type | No | Filter by event type (default: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is retrieved ('executions, queued transactions, approvals, cancellations, spend policy updates, and operator changes') but lacks details on permissions, rate limits, pagination, or error handling. It adds some context about filtering but is incomplete for a read operation with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific details and usage guidance in the second. Both sentences are essential—no wasted words—making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what data is retrieved and filtering options, but lacks details on return format, error cases, or prerequisites. Without annotations or output schema, more behavioral context would improve completeness for a historical query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning filtering by 'event type or block range', which aligns with the schema but does not provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve') and resource ('wallet's recent on-chain transaction history from event logs'), and distinguishes this tool from siblings by focusing on historical transaction data rather than current operations (like check_spend_limit) or wallet management (like deploy_wallet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Filter by event type or block range for targeted queries'), but does not explicitly state when to use this tool versus alternatives like get_wallet_info or when not to use it. It implies usage for historical queries without naming specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive wallet information including address, on-chain balance, spend limits, remaining period allowance, and queue depth. Use token parameter to check budget for a specific ERC20 (defaults to ETH).
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Token address to check. Use "0x0000000000000000000000000000000000000000" for ETH (default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and scope (read-only data retrieval for wallet status), but lacks details on potential errors, rate limits, authentication needs, or response format. It adds value beyond the schema by explaining the token parameter's purpose, but does not fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific usage guidance. Both sentences are essential—the first defines scope, the second explains parameter usage—with zero redundant or vague language, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 optional parameter, no output schema, no annotations), the description is adequate but has gaps. It clearly explains what the tool does and parameter usage, but lacks details on output structure, error conditions, or dependencies. Without annotations or output schema, the description does not fully compensate for these missing elements, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds meaningful context by explaining that the token parameter is used 'to check budget for a specific ERC20' and defaults to ETH, which clarifies the semantic purpose beyond the schema's technical specification. This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get comprehensive wallet information') and enumerates the exact data returned (address, on-chain balance, spend limits, remaining period allowance, queue depth). It distinguishes from siblings like 'get_transaction_history' (historical data) or 'check_spend_limit' (specific limit check) by emphasizing comprehensive status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to check budget for a specific ERC20') and mentions the default behavior (defaults to ETH). However, it does not explicitly state when to use alternatives like 'check_spend_limit' for focused limit queries or 'get_transaction_history' for past activity, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage over-limit transactions queued for owner review. Use action="list" to see pending transactions, "approve" to approve one by ID, or "cancel" to cancel one by ID. Approve/cancel require the agent key to have owner privileges.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: "list", "approve", or "cancel" | |
| tx_id | No | Transaction queue ID (required for approve/cancel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool manages queued transactions for review, requires owner privileges for approve/cancel actions, and implies mutation capabilities (approve/cancel are destructive). However, it lacks details on error handling, rate limits, or response formats, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by usage instructions and prerequisites in two concise sentences. Every sentence adds essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by covering purpose, usage, and behavioral aspects like privileges. However, it lacks details on return values, error cases, or pagination for the list action, which could be important for a tool with mutation capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantics of the 'action' parameter (list for pending transactions, approve/cancel by ID) and clarifying that 'tx_id' is required for approve/cancel, which enhances understanding beyond the schema's enum and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage over-limit transactions queued for owner review.' It specifies the verb ('manage') and resource ('over-limit transactions'), distinguishing it from sibling tools like check_spend_limit or send_payment, which handle different aspects of transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use action="list" to see pending transactions, "approve" to approve one by ID, or "cancel" to cancel one by ID.' It also specifies prerequisites: 'Approve/cancel require the agent key to have owner privileges,' clearly indicating when and how to use each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send ETH or ERC20 tokens from the Agent Wallet. If the amount is within the configured spend limits, it executes immediately and returns the tx hash. If it exceeds limits, the transaction is queued for owner approval (use queue_approval to manage). Always check spend limits first with check_spend_limit to avoid surprises.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address (0x-prefixed) | |
| amount_eth | Yes | Amount in ETH (or token units). E.g. "0.001" for 0.001 ETH, "1.5" for 1.5 USDC | |
| token | No | ERC20 token address. Omit for native ETH. | |
| token_decimals | No | Token decimals (default 18 for ETH, 6 for USDC) | |
| memo | No | Optional memo for this payment (not stored on-chain) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: immediate execution within limits, queuing for owner approval if exceeding limits, and the need to check limits first. It doesn't cover rate limits or auth needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose, conditional behavior, and prerequisite action. Every sentence adds value—no wasted words—and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment tool with no annotations and no output schema, the description does well by explaining the execution flow (immediate vs. queued) and linking to related tools. It could mention return values (tx hash) more explicitly, but overall it's quite complete given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain token address format or memo usage further). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send ETH or ERC20 tokens from the Agent Wallet.' It specifies the action (send), resources (ETH/ERC20 tokens), and source (Agent Wallet), distinguishing it from siblings like check_spend_limit or get_transaction_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'Always check spend limits first with check_spend_limit to avoid surprises.' It also explains what happens if limits are exceeded (queued for approval, use queue_approval to manage), offering clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and automatically handle HTTP 402 Payment Required responses. If an active x402 V2 session covers this URL, the session token is used instead of making a new payment (no on-chain cost). If no session exists, the Agent Wallet pays the required amount and retries. Payment is rejected if it exceeds your wallet's spend limits or the max_payment_eth cap. Powered by the x402 protocol on Base network. Tip: Use x402_session_start to pay once for a session and save on repeated calls.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch (HTTP 402 responses are handled automatically) | |
| method | No | HTTP method (default: GET) | GET |
| headers | No | Additional request headers | |
| body | No | Request body string (for POST/PUT/PATCH) | |
| max_payment_eth | No | Maximum payment cap in ETH (e.g. "0.001") | |
| timeout_ms | No | Timeout in milliseconds (default: 30000) | |
| skip_session_check | No | Skip session auto-detection and force a fresh x402 payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic handling of HTTP 402 responses, session token usage to avoid costs, payment rejection based on spend limits or max_payment_eth cap, and the underlying x402 protocol on Base network. However, it lacks details on error handling or response formats, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core functionality stated first. Each sentence adds value: explaining session handling, payment logic, rejection conditions, protocol details, and a usage tip. There is no wasted text, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (payment handling, session management) and no annotations or output schema, the description is largely complete. It covers the main behavioral aspects and usage context. However, it could benefit from more details on error scenarios or response formats to achieve full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as implying 'url' is the target for payment handling and 'max_payment_eth' sets a cap. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching a URL while automatically handling HTTP 402 Payment Required responses. It specifies the verb ('fetch') and resource ('URL'), and distinguishes it from siblings by mentioning the x402 protocol and session handling capabilities, unlike generic payment or session tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives. It states to use 'x402_session_start to pay once for a session and save on repeated calls,' indicating an alternative for cost-saving scenarios. It also implies usage for URLs requiring payment, with no misleading suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly close an x402 V2 session before it expires naturally. After calling this, x402_session_fetch will return an error for the closed session. Useful for security hygiene or when you know a session is no longer needed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID to close (from x402_session_start) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a destructive operation (closes a session), has side effects (x402_session_fetch will return an error), and mentions security implications. It doesn't cover rate limits or authentication needs, but provides substantial context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core action and immediate effect, the second provides usage context. Every phrase adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive operation with security implications), no annotations, and no output schema, the description does well by explaining the action, effects, and usage scenarios. It could be more complete by mentioning authentication requirements or response format, but it covers the essential context for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the session_id parameter fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('explicitly close') and resource ('an x402 V2 session'), distinguishing it from siblings like x402_session_fetch, x402_session_start, and x402_session_status. It precisely defines what the tool does beyond just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('before it expires naturally', 'useful for security hygiene or when you know a session is no longer needed') and provides a clear alternative (letting it expire naturally). It also mentions the consequence for x402_session_fetch, guiding usage relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP request within an established x402 V2 session — NO payment required. The session token (signed by your wallet) is automatically attached to the request. The server recognises your session and grants access without a new on-chain payment. Requires a session_id from x402_session_start. Returns an error if the session has expired (call x402_session_start again to renew).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID from x402_session_start | |
| url | Yes | URL to fetch (must be covered by the session) | |
| method | No | HTTP method (default: GET) | GET |
| headers | No | Additional headers (session token is injected automatically) | |
| body | No | Request body for POST/PUT/PATCH | |
| timeout_ms | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it automatically attaches the session token, grants access without payment, and returns an error for expired sessions. However, it lacks details on rate limits, authentication needs beyond the session, or what specific errors might occur, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential context and error handling. Every sentence adds value—no wasted words—and it's structured logically from usage to prerequisites to error resolution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (session-based HTTP requests with 6 parameters), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, prerequisites, and error handling, but lacks details on return values or advanced behavioral traits like rate limits, which would be helpful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only implying that the URL must be 'covered by the session' and noting automatic token injection, but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Make an HTTP request within an established x402 V2 session') and resource (session-based HTTP requests), distinguishing it from siblings like x402_session_start (which creates sessions) and x402_pay (which involves payments). It explicitly notes 'NO payment required' to differentiate from payment-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('within an established x402 V2 session'), prerequisites ('Requires a session_id from x402_session_start'), and alternatives for errors ('call x402_session_start again to renew'). It also clarifies when not to use it ('NO payment required'), distinguishing it from payment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Establish an x402 V2 payment session: make a SINGLE on-chain payment and receive a cryptographically signed session token. All subsequent calls to the same endpoint within the session lifetime use x402_session_fetch — no additional payments required. Agents pay once per session rather than once per API call. Session tokens are signed locally by your wallet key (non-custodial). Returns a session_id you pass to x402_session_fetch for all future calls.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | Base URL to establish a session for (e.g., "https://api.example.com/v1") | |
| scope | No | "prefix": covers all paths under this URL (default). "exact": single URL only. | prefix |
| ttl_seconds | No | Session TTL in seconds (default: 3600 / 1 hour). Max: 30 days. | |
| label | No | Optional label for this session (e.g., "Premium API session") | |
| max_payment_eth | No | Maximum ETH to pay for this session. Rejects if price exceeds this. | |
| method | No | HTTP method for the initial request (default: GET) | GET |
| headers | No | Additional request headers | |
| body | No | Request body for POST/PUT/PATCH session-start requests | |
| timeout_ms | No | Request timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the payment mechanism (on-chain payment), session token characteristics (cryptographically signed, non-custodial), session lifetime concept, and the relationship with x402_session_fetch. It could be improved by mentioning error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently conveys essential information in four sentences. Each sentence adds value: establishing the session, explaining the session-fetch relationship, describing the payment model, and detailing the token characteristics. There's no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, the description provides good context about the tool's purpose, usage patterns, and behavioral characteristics. It explains the return value (session_id) and how to use it. It could be more complete by mentioning error conditions or providing examples of typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds some context about the session establishment process but doesn't provide additional parameter-specific semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Establish an x402 V2 payment session' with specific details about making a single on-chain payment and receiving a signed session token. It distinguishes from sibling tools like x402_session_fetch by explaining the relationship between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'All subsequent calls to the same endpoint within the session lifetime use x402_session_fetch — no additional payments required.' It clearly explains when to use this tool versus its sibling x402_session_fetch, and mentions the 'Agents pay once per session rather than once per API call' principle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of x402 V2 payment sessions. Without arguments, lists all active sessions with TTL remaining. With a session_id, shows full details for that session including call count, payment info, and the signed session token.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Specific session ID to inspect. Omit to list all active sessions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool can list sessions or show details, but lacks information on permissions, rate limits, error conditions, or response format. It adds some context about TTL and details like call count and payment info, but behavioral traits are incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, with two sentences that efficiently cover purpose and usage without wasted words. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read-only tool. It explains what the tool does and how to use it, but lacks details on return values, error handling, or operational constraints, leaving gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameter. The description adds value by explaining the semantic effect: omitting the parameter lists all active sessions, while including it shows full details for a specific session. This goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check', 'lists', 'shows') and resources ('x402 V2 payment sessions'), and distinguishes it from siblings by focusing on session status rather than creation, ending, or payment actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Without arguments, lists all active sessions with TTL remaining. With a session_id, shows full details for that session.' This provides clear guidance on usage based on parameter presence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.0.1check_spend_limitdeploy_walletget_transaction_historyget_wallet_infoqueue_approvalsend_paymentx402_payx402_session_endx402_session_fetchx402_session_startx402_session_statusScored across 11 tools
The tools are mostly distinct with clear purposes, but there is some overlap between check_spend_limit and send_payment, as both involve spend limit checks, which could cause minor confusion. The x402 session tools are well-differentiated, and other tools like deploy_wallet and get_transaction_history have unique functions.
Naming is mostly consistent with a verb_noun pattern, such as check_spend_limit and send_payment, but there are minor deviations like x402_pay (which mixes protocol prefix with verb) and the x402_session_* tools that use a consistent prefix but vary in verb style. Overall, it's readable with only slight inconsistencies.
With 11 tools, the count is well-scoped for managing AgentPay wallets and x402 payments. Each tool serves a specific purpose, such as deployment, transactions, and session management, without feeling excessive or insufficient for the domain.
The tool set provides comprehensive coverage for wallet management and x402 payment handling. It includes deployment, transaction sending, limit checks, history retrieval, approval queuing, and full session lifecycle management, leaving no obvious gaps for the intended use cases.
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
Policy-gated MCP treasury for AI agents — x402 subscribe, 50+ tools, multi-chain.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
Agent Commerce Protocol MCP — bridges Stripe ACP + Google AP2 + Coinbase x402 for agent payments