Skip to main content
Glama
valta-mcp

valta-mcp

by Valta-hq

valta-mcp

CI License: MIT

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.

How Valta MCP works

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-mcp

Or run directly without installing:

npx valta-mcp

Configuration

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

valta_check_balance

Read an agent's wallet balance and limits

valta_request_spend

Request authorization for a spend — approved or denied by the real spend gate

valta_create_wallet

Create a new named wallet with optional spend limits

valta_freeze_agent

Kill switch — freeze an agent's wallet, blocking further spend

valta_unfreeze_agent

Resume a frozen agent's wallet

valta_get_audit_trail

Read the hash-chained audit trail of spend decisions

valta_list_wallets

List all named wallets on the account — use this to discover wallet names before checking balance/spending

valta_transfer_funds

Transfer USDC directly between two of your agent wallets

valta_list_agents

List all agents on the account

valta_get_agent

Get details for a single agent

valta_run_agent

Trigger an agent to run a task

valta_get_agent_run

Check the status/result of a specific agent run

valta_list_policies

List spending policies configured on the account

valta_set_policy

Create a new spending policy (daily cap, per-transaction cap)

valta_proxy_request

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

valta_list_proxy_requests

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:

  1. 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 instructions field — it cannot inject a binding, universally-enforced rule into the conversation.

  2. 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_spend is 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_request is 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 tools
valta_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

    A3.7/5.0

    Scored across 16 tools

    Disambiguation5/5

    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.

    Naming Consistency4/5

    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.

    Tool Count4/5

    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.

    Completeness4/5

    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

    ActivityInactive
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers