Valta

valta-mcp

Valta の MCP（Model Context Protocol）サーバーです。AI エージェント向けの財務ガバナンスを提供します。Valta の支出ゲートと監査証跡を MCP ツールとして公開するため、MCP 互換のクライアント（Claude Desktop、Claude Code、Cursor など）から直接呼び出せます。

できることと、できないこと

このサーバーは、Valta の実際のホスト型 REST API を薄くラップしたものです。支出ロジック、上限、ハッシュ処理を独自に実装することはなく、ここでのすべてのツール呼び出しは https://valta.co/api/v1/... へのパススルーです。実際の制御（支出ゲート、監査チェーン）はそこで行われます。このリポジトリはプロトコルアダプターであり、制御エンジンではありません。

重要：セキュリティに関わる用途で利用する前にお読みください。これらのツールの大半は強制力を持たず、助言を提供するものです。モデルに「支出前にこれを呼び出してください」と伝えるツールの説明はガイダンスであり、保証ではありません。たとえば、valta_request_spend が制御するのは、このツールを経由する支出のみです。エージェントが独自にアクセスできる別のツール、API、Webhook を通じて発生する支出を傍受したり、防いだりすることはありません。

**1つだけ異なるツールがあります：valta_proxy_request。**ほかの場所で支出する前にモデルに確認させるのではなく、このツール自体が支出を実行します。エージェントが外部呼び出しの費用を申告し、実際の呼び出しを Valta 経由で行うと、Valta はウォレットの上限と照合し、承認された場合に限り、保存済みのユーザー自身の認証情報を使って実際のリクエストを実行します。ブロックされた場合、実際のプロバイダーに接続することはありません。これは信頼に依存する運用ルールではなく、コードレベルで保証されます。ただし、対象となるのは Valta がプロキシ用に接続済みの特定のサービス（現在は Stripe、Serper、Polygon）に限られます。このプロキシ以外の経路、たとえばエージェント自身の別の API キー、Webhook、このサーバーが認識していないツールを通じて発生する支出は、いずれのツールからも把握・停止できません。以下の設計に関する注意点を参照してください。

インストール

npm install -g valta-mcp

インストールせずに直接実行することもできます。

npx valta-mcp

設定

valta.co/dashboard → Settings → API Keys → Create key から API キーを取得します。

MCP クライアントの設定に追加してください（例：Claude Desktop の claude_desktop_config.json）。

{
  "mcpServers": {
    "valta": {
      "command": "npx",
      "args": ["valta-mcp"],
      "env": {
        "VALTA_API_KEY": "sk_valta_your_key_here"
      }
    }
  }
}

ツール

ツール	機能
valta_check_balance	エージェントのウォレット残高と上限を確認します
valta_request_spend	支出の承認をリクエストします — 実際の支出ゲートによって承認または拒否されます
valta_create_wallet	任意の支出上限を設定して、新しい名前付きウォレットを作成します
valta_freeze_agent	キルスイッチ — エージェントのウォレットを凍結し、以後の支出をブロックします
valta_unfreeze_agent	凍結されたエージェントのウォレットを再開します
valta_get_audit_trail	ハッシュチェーンで連結された支出判断の監査証跡を読み取ります
valta_list_wallets	アカウント上のすべての名前付きウォレットを一覧表示します — 残高確認や支出の前にウォレット名を確認するために使用します
valta_transfer_funds	自分の2つのエージェントウォレット間でUSDCを直接送金します
valta_list_agents	アカウント上のすべてのエージェントを一覧表示します
valta_get_agent	単一のエージェントの詳細を取得します
valta_run_agent	エージェントにタスクの実行を指示します
valta_get_agent_run	特定のエージェント実行のステータスや結果を確認します
valta_list_policies	アカウントに設定された支出ポリシーを一覧表示します
valta_set_policy	新しい支出ポリシー（日次上限、取引ごとの上限）を作成します
valta_proxy_request	Valtaの支出ゲート付きエグレスプロキシ経由で、接続済みサービス（Stripe、Serper、Polygon）に実際のアウトバウンドリクエストを送信します — 事前にコストを申告し、承認された場合のみ実際のプロバイダーに接続します。失敗時は自動的に返金されます
valta_list_proxy_requests	エグレスプロキシが処理したすべての呼び出しのレシートを一覧表示します — 許可、ブロック、返金、承認待ちの別とその理由を確認できます

src/index.tsにある各ツールの説明には、そのツールが適用する制約と適用しない制約が明記されています。実際のお金に関わる用途に組み込む前に、必ずお読みください。

設計上の注意点

「バイパスできないシステムプロンプト」がない理由。 このプロジェクトの初期草案では、支出ゲートを「バイパスできない」ものにすると主張するシステムプロンプト用の指示ブロックを同梱する案が検討されていました。しかし、その主張は成り立ちません。理由は2つあります。

1. MCP サーバーはホストのシステムプロンプトを制御できません。 Claude Desktop、Claude Code、Cursorなどのホストは、それぞれ独自のシステムプロンプトを管理しています。MCP サーバーが提供できるのはツールと、場合によっては限定的なinstructionsフィールドです。会話に対して拘束力のある、普遍的に適用されるルールを注入することはできません。
2. システムプロンプトはモデルへのリクエストであり、コードレベルの制約ではありません。 ホストがサーバーの指示を表示する場合でも、エージェントはプロンプトインジェクションを受けたり、ジェイルブレイクされたり、このサーバーをまったく呼び出さない別のツール経由で処理されたりする可能性があります。そうでないと主張することは、まさにこのプロジェクトが解消しようとしている種類の抜け穴です。モデルが自らを律することを信頼するのは、そもそもValtaの支出ゲートが避けるために作られた失敗の原因です。

実際に保証できることと、できないこと。 このサーバーには現在、異なるレベルの適用方法が2つあります。各ツールがどちらに該当するかが重要です。

• valta_request_spendを呼び出して承認された支出は、サーバー側で実際の上限と照合されます。ただし、これはエージェントが最初にこのツールを呼び出した場合に限ります。抜け穴となるのは、エージェントがアクセスできる別の経路で発生する支出です。
• valta_proxy_request経由の支出は、実際の呼び出しを行う前にチェックされます。支払いを発生させる呼び出しとチェックが同じアクションであるため、エージェントがチェックを省略しながら支払いだけを実行する段階はありません。これにより上記の抜け穴はふさがれますが、対象となるのはこのサーバーがプロキシ用に接続したサービス（この文書の執筆時点ではStripe、Serper、Polygon）に限られます。新しいサービスへの対応には、設定フラグを切り替えるのではなく、そのプロバイダー固有の認証方式に対応した実際の認証情報処理ロジックを追加する必要があります。

上記にまだ記載されていないサービスについて、ユースケース上、確実な保証が必要な場合は、まずそのサービスをValtaのプロキシゲートに追加する必要があります。issueまたはPRを作成してください。

ライセンス

MIT。