Give AI agents a wallet with a spending limit. Non-custodial USDC on Base, server-enforced limits.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
One-click editor setup isn’t available for this listing yet — we don’t have a confirmed install command, and we’d rather show nothing than point your editor at the wrong package or host. Follow the project’s own setup instructions, linked above.
Give your AI agent a wallet with a spending limit.
MCP server + typed client for Veyra: non-custodial USDC payments on Base, with per-payment caps, daily caps, human approval bands and a recipient allowlist — all enforced server-side, never by the model.
Agents increasingly need to pay for things: an API call, a dataset, a bounty, another agent. Today the choices are bad:
Veyra is the layer in between. You connect a wallet you already own, set what an agent may spend, and hand the agent one MCP endpoint. The agent gets tools like create_payment. It never sees a key, and it cannot exceed the limits you set because the limits are enforced by Veyra's server, not by the model following instructions.
veyra_)..cursor/mcp.json)claude_desktop_config.json)The veyra-mcp binary is a stdio bridge: it holds the credential locally and relays every call to the hosted endpoint. No policy lives in the bridge.
Then ask the agent to do something that costs money and watch the policy decide.
| Tool | What it does |
|---|---|
get_capabilities | Rails, networks, assets, limits and the recipient allowlist in force right now |
get_budget | Daily limit, spent today, per-payment limit, auto and ask bands |
list_payment_sources | Masked sources and whether each can settle without a human |
create_payment | Create a payment intent. Policy is applied server-side and the result says what happened |
get_payment | Canonical state for one payment, including which rail settled it |
list_payments | Recent payments for this endpoint |
cancel_payment | Cancel while still cancellable |
Every payment reports one of these statuses:
| Status | Meaning |
|---|---|
confirmed | Value moved on-chain |
confirmed_simulated | Settled on the simulated rail. No money moved. The agent is told this explicitly |
awaiting_approval | In the ask band. next_action.url is a one-time link the owner opens in their own wallet |
submitted | Transaction sent, waiting for the chain receipt |
pending | Created, not yet evaluated or executed |
failed / cancelled / expired | Terminal. Blocked-by-policy payments are failed with a policy_reason |
This is the one thing worth reading twice. A payment the policy declines comes
back as an ordinary result with status: "failed" — the call did what it was
asked and the answer was no. Only a malformed argument, a bad credential or an
unknown id throws.
So try/catch is the wrong tool for detecting refusals: it misses every
blocked payment and reads it as a success. Use paymentOutcome, and use
movedRealMoney before telling anyone value moved — it returns false for a
simulated settlement even though the status begins with "confirmed".
Reserve catch for what genuinely failed:
If you cannot tell whether a payment worked, read it — do not create
another. getPayment returns tx_ref once a real payment has settled, which
is both your confirmation and what you show the recipient as proof. Reusing the
same idempotency_key returns the original payment; a new key spends again.
Veyra also sets possible_duplicate_of when an identical payment to the same
recipient is already live.
VEYRA_TOOLS exports the tool definitions as JSON Schema, so you can register them with the Vercel AI SDK, LangChain, or plain function calling without a network round-trip. See veyra-examples for complete agents built with the Claude Agent SDK and the Vercel AI SDK.
Worth being blunt, because this is money.
approve primitive every DeFi app uses. The token contract enforces the cap. Veyra's policy engine decides the destination within that cap, so size the allowance like a float you could lose, and use the recipient allowlist when you know who the agent should be paying. Revoke it any time.confirmed_simulated, simulated: true.Full details: How a payment actually moves and What you are trusting, exactly.
Which networks and assets? USDC on Base. One stablecoin keeps the dollar limits exact without a price feed, and Base is where the agent-payment ecosystem already settles. More rails are on the roadmap; open an issue if you need one.
Does this work with x402 or pay-per-call APIs? Yes, in the sense that matters: the agent asks Veyra to pay the seller's address and gets a receipt. Veyra is the spending policy, not the protocol on the other end.
Can I self-host? Not today. This repo is the client and bridge; the policy engine is the hosted service at veyra.money. The wallet-approval path is fully non-custodial regardless.
What does it cost? There is a free plan. See pricing.
No reviews yet — be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/veyra)<a href="https://allmcps.com/mcp/veyra"><img src="https://allmcps.com/api/badge/veyra?style=directory" alt="Veyra on AllMCPs" /></a>