valta-mcp
The valta-mcp server provides a Model Context Protocol (MCP) interface for Valta's financial governance platform, enabling AI agents to manage wallets, control spend, enforce limits, and route real API calls through a spend-gated egress proxy.
Wallet & Balance Management
Check an agent's current balance and spend limits
Create new wallets with optional daily, monthly, and per-transaction USDC limits
List all wallets on the account with balances and configured limits
Transfer USDC between agent wallets
Spend Authorization & Control
Request spend authorization through Valta's spend gate (returns approval with new balance or denial with reason)
Freeze/unfreeze an agent's wallet as an immediate kill switch
Policy Management
List all spending policies, optionally filtered to one agent
Set named policies with daily and/or per-transaction USDC caps
Audit Trail
Read a tamper-evident, hash-chained log of all spend decisions (approved and denied) for one or all agents
Agent Management
List all agents on the account, or get details for a specific agent
Trigger an agent to run a task and poll the status/result of that run
Spend-Gated Egress Proxy
Route real outbound API calls to connected services (currently Stripe, Serper, Polygon) through Valta's proxy — the declared cost is checked against wallet limits before the real provider is contacted; blocked calls never reach the provider and failed calls are automatically refunded
Review receipts for every proxied call (allowed, blocked, refunded, or pending) and the reason why
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@valta-mcp Authorize $50 for OpenAI API usage"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
valta-mcp
An MCP (Model Context Protocol) server for Valta — financial governance for AI agents. Exposes Valta's spend gate and audit trail as MCP tools, so any MCP-compatible client (Claude Desktop, Claude Code, Cursor, and others) can call them directly.

What this is — and isn't
This server is a thin wrapper over Valta's real, hosted REST API. It does not implement any spend logic, limits, or hashing itself — every tool call here is a pass-through to https://valta.co/api/v1/..., where the actual enforcement (spend gate, audit chain) happens. This repo is the protocol adapter, not the enforcement engine.
Important, read before relying on this for anything security-sensitive: most of these tools are advisory, not enforcing. A tool description telling a model "call this before spending" is guidance, not a guarantee. valta_request_spend, for example, only governs spend that routes through it — it does not intercept or prevent spending that happens through some other tool, API, or webhook the agent has independent access to.
One tool is different: valta_proxy_request. Instead of asking the model to check in before spending elsewhere, this one is the spend — the agent declares an outbound call's cost and routes the actual call through Valta, which checks it against wallet limits and only makes the real request (using your own stored credential) if approved. If it's blocked, the real provider is never contacted at all. This is a genuine, code-level guarantee, not an honor system — but only for the specific services Valta has wired up for proxying (currently: Stripe, Serper, Polygon). Any spend that happens through a channel other than this proxy — the agent's own separate API key, a webhook, a tool this server doesn't know about — is outside what any of these tools can see or stop. See Design notes below.
Related MCP server: Payments Agent Gateway (MCP)
Install
npm install -g valta-mcpOr run directly without installing:
npx valta-mcpConfiguration
Get an API key at valta.co/dashboard → Settings → API Keys → Create key.
Add to your MCP client's config (e.g. Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"valta": {
"command": "npx",
"args": ["valta-mcp"],
"env": {
"VALTA_API_KEY": "sk_valta_your_key_here"
}
}
}
}Tools
Tool | What it does |
| Read an agent's wallet balance and limits |
| Request authorization for a spend — approved or denied by the real spend gate |
| Create a new named wallet with optional spend limits |
| Kill switch — freeze an agent's wallet, blocking further spend |
| Resume a frozen agent's wallet |
| Read the hash-chained audit trail of spend decisions |
| List all named wallets on the account — use this to discover wallet names before checking balance/spending |
| Transfer USDC directly between two of your agent wallets |
| List all agents on the account |
| Get details for a single agent |
| Trigger an agent to run a task |
| Check the status/result of a specific agent run |
| List spending policies configured on the account |
| Create a new spending policy (daily cap, per-transaction cap) |
| Make a real outbound call to a connected service (Stripe, Serper, Polygon) through Valta's spend-gated egress proxy — declares a cost up front, only reaches the real provider if approved, refunds automatically on failure |
| List the receipts for every call the egress proxy has handled — allowed, blocked, refunded, or pending approval, and why |
Every tool's description in src/index.ts states plainly what it enforces and what it doesn't — read those before wiring this into anything that touches real money.
Design notes
Why there's no "non-bypassable system prompt." An earlier draft of this project considered shipping a system-prompt instruction block claiming to make spend gating "non-bypassable." That claim doesn't hold up, for two reasons:
MCP servers don't control the host's system prompt. Claude Desktop, Claude Code, Cursor, and other hosts each own their own system prompt. An MCP server provides tools and, in some cases, a limited
instructionsfield — it cannot inject a binding, universally-enforced rule into the conversation.A system prompt is a request to the model, not a code-level constraint. Even where a host does surface server instructions, an agent can still be prompt-injected, jailbroken, or simply routed through a different tool entirely that doesn't call this server at all. Claiming otherwise would be exactly the kind of gap this project exists to close — trusting the model to self-police is the failure mode Valta's spend gate was built to avoid in the first place.
What actually provides a guarantee, and what doesn't. There are now two different levels of enforcement in this server, and it matters which one a given tool gives you:
Spend authorized by calling
valta_request_spendis genuinely checked against real limits, server-side — but only if the agent chooses to call it first. The gap is spend that happens through some other channel the agent has access to.Spend routed through
valta_proxy_requestis checked before the real call is made at all — there's no step where the agent could skip the check and still have the payment go through, because the payment-triggering call and the check are the same action. That closes the gap described above, but only for the services this server has wired up for proxying (Stripe, Serper, Polygon as of this writing) — extending it to a new service means adding real credential-handling logic for that provider's specific auth scheme, not flipping a config flag.
If a use case needs a hard guarantee for a service not yet listed above, that service needs to be added to Valta's proxy gate first — open an issue or a PR.
License
MIT.
Available Tools
16 toolsvalta_check_balanceA
Check an agent's Valta wallet balance and spend limits. Call this before attempting a spend to confirm funds are available. This does not spend anything.
Inputs: agentId (required).
valta_create_walletA
Create a new named Valta wallet with optional spend limits. Use this to set up governance for a new agent before it starts spending.
Inputs: name (required), dailyLimit, perTxLimit, monthlyLimit.
valta_freeze_agentA
Immediately freeze an agent's Valta wallet, blocking all further spend through Valta. Use this as a kill switch when an agent is behaving unexpectedly.
Inputs: agentId (required).
valta_get_agentB
Get details for a single agent, including status and balance.
Inputs: agentId (required).
valta_get_agent_runB
Check the status and result of a specific agent run.
Inputs: runId (required), agentId (required).
valta_get_audit_trailA
Read the tamper-evident, hash-chained audit trail of spend decisions (approved and denied) for an agent, or across all agents if no agentId is given.
Inputs: limit, agentId.
valta_list_agentsB
List all agents on this account — both marketplace subscriptions and custom SDK-created agents.
Inputs: limit, offset.
valta_list_policiesA
List spending policies (limits, approval thresholds) configured on this account, optionally filtered to one agent.
Inputs: agentId.
valta_list_proxy_requestsA
List the receipts for every call made through Valta's spend-gated egress proxy — what was allowed, blocked, refunded, or left pending approval, and why. Optionally filter to one agent.
Inputs: limit, agentId.
valta_list_walletsA
List all named Valta wallets on this account, with balances and limits. Use this to discover what wallets exist before checking a balance or requesting a spend — you need to know the exact wallet name/ID first.
Inputs: no named parameters.
valta_proxy_requestA
Make a real outbound API call to a connected service (e.g. Stripe) through Valta's spend-gated egress proxy, instead of calling the provider directly. Declare the amount this call will cost up front — Valta checks it against the agent's wallet limits (freeze state, per-transaction/daily/monthly caps, approval thresholds) and only makes the real request if approved, using the account's own stored credential for that service. If the upstream call fails, the declared amount is automatically refunded. Only services with proxying enabled can be called this way — currently: stripe, serper, polygon.
Inputs: path (required), amount (required), method (required), agentId (required), +4 more.
valta_request_spendA
Request authorization to spend from an agent's Valta wallet. Returns approved with a new balance, or denied with a reason. IMPORTANT: this tool only governs spend that routes through it — it does not intercept or prevent spending done via other tools, APIs, or webhooks that don't call this tool first. If denied, do not proceed with the action and inform the user why.
Inputs: amount (required), agentId (required), description (required), category.
valta_run_agentA
Trigger an agent to run a task. Returns the run's execution ID and initial status.
Inputs: task (required), agentId (required), context.
valta_set_policyB
Create a new spending policy — a named limit configuration (daily cap, per-transaction cap) that can be applied to an agent's spend.
Inputs: name (required), agentId, maxSpendPerDay, maxSpendPerTransaction.
valta_transfer_fundsC
Transfer USDC directly between two of your agent wallets.
Inputs: amount (required), toAgentId (required), fromAgentId (required), description.
valta_unfreeze_agentA
Unfreeze a previously frozen agent's Valta wallet, allowing spend to resume.
Inputs: agentId (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 16 tools
Each tool targets a distinct operation: wallet management, agent control, spend authorization, proxy requests, audit, etc. There is no noticeable overlap; even seemingly similar tools like check_balance and list_wallets serve different purposes.
Tools consistently use snake_case and start with 'valta_'. Most follow a verb_noun pattern (e.g., create_wallet, freeze_agent), though 'proxy_request' is noun_verb, which is a minor deviation. Overall, naming is clear and predictable.
With 16 tools, the server is slightly above the ideal 3-15 range, but the number is still reasonable given the domain's complexity. No tool feels superfluous, and the set covers essential operations without being bloated.
The tool surface covers core workflows: wallet lifecycle (create, list, balance, transfer), agent management (list, get, run, freeze/unfreeze), spending policies (list, set), spend authorization, proxy requests, and audit. Minor gaps exist (no update/delete for wallets or agents), but these are not critical for the primary purpose of spend governance.
Maintenance
Related MCP Connectors
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Ledger of record for AI spend: verifiable receipts, waste auditor & model arbitrage MCP.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to safely interact with a double-entry payments ledger, enforcing idempotency, policy-based access control, and human-in-the-loop approval for high-value actions.-
- AlicenseAqualityDmaintenanceAn MCP server that provides programmable spend limits and audit trails for AI agents to make payments from a dedicated wallet, preventing overspend and unauthorized transactions.8MIT
- AlicenseAqualityCmaintenanceMCP server that enables AI agents to request human approval before spending money, check approval status, verify signed tokens, and manage API keys.911 npmMIT