warda

@warda_protocol/mcp

エージェントフレームワークが自身の経済的権限について推論し、助成金のライフサイクル全体（支出、委任、精算、取り消し、記録が古くなった場合の再発見）を実行できるようにする MCP サーバーです。Kaspa との連携は不要です。

インストールも、ご自身の Kaspa も必要ありません。これをクライアントの設定（Claude Desktop の場合は claude_desktop_config.json、Cursor の場合は .cursor/mcp.json）に追加し、再起動してください。

{
  "mcpServers": {
    "warda": { "command": "npx", "args": ["-y", "@warda_protocol/mcp"] }
  }
}

空の npm キャッシュから起動した場合、11 個のツールが利用可能になるまで約 7 秒です。

npx -y @warda_protocol/mcp     # the same thing, by hand, speaking stdio

チェックアウトから起動する場合：

node --experimental-strip-types src/server.ts    # stdio
npm test                                          # 34 tests, real transport

この最後の 2 つだけが以前はこのセクションのすべてでした。しかし、このファイルを読む人は MCP レジストリから来て、何かをクローンすることはないため、適切な手順ではありませんでした。

ビルドはします。署名も強制もしません。

warda_build_spend は、署名なしのトランザクションと署名対象のダイジェストを返します。**このサーバーが鍵を目にすることはありません。**エージェントの鍵を保持する者が、その鍵のある場所でダイジェストに署名し、65 バイトを固定幅のスロットに挿入してブロードキャストします。署名する MCP サーバーはカストディアンになります。誰もカストディアンになる必要がないことが Warda の要点です。

テストでは、ビルドされたすべてのトランザクションで署名スロットが 65 バイトのゼロのままであり、レスポンスのどこにも鍵のマテリアルが現れないことを確認します。

ここでは何も強制しません

エージェントは、このサーバーからのあらゆる回答を無視し、トランザクションを構築してブロードキャストしてもかまいません。**コベナントがそれを拒否します。**Warda のセキュリティは、エージェントが先に許可を求めることを前提としていません。それが根本的な前提であり、そうであるかのように示すサーバーは、提供するプロトコルと矛盾します。

すべてのレスポンスには enforcement というフィールドでその旨が示されており、テストでもそのフィールドがあることを確認します。

では、何のためにあるのでしょうか

• **余裕額。**購入を計画するエージェントには、現在支払える最大額が必要です。それは単一のフィールドではなく、残予算、エポックの余裕額、トランザクションごとの上限の最小値です。warda_grant_authority がこれを計算します。
• **無駄なトランザクションの防止。**コベナントに拒否される支出には、手数料と往復の時間がかかります。事前に確認するほうが低コストです。
• **言葉による拒否理由。**オンチェーンでは、ルールに違反すると、すべて不透明なスクリプトエラーにまとめられます。ここでは拒否理由として該当するルールと対処法を示します。たとえば、VerifyError ではなく、*「トランザクションごとの上限を超えています。分割するか、プリンシパルに上限を引き上げてもらってください」*と伝えます。
• **発見。**MCP を使うフレームワークは、独自の連携なしで Warda を見つけられます。それが仕様の §20 の要点です。

ルールは一箇所にあります

すべての判定は @warda_protocol/core から行われます。これは、同じ 45 個のテストを共有する、コベナントの検証に使われたコードそのものです。このサーバーはプロトコルのルールを複製していません。

これは意図的な制約です。ルールを二重に実装すると内容にずれが生じ、どちらの場合も問題になります。チェーンが拒否するのにエージェントへ支出可能と伝えれば資金を無駄にし、チェーンが許可するのに支出不可と伝えれば資金を使えないままにしてしまいます。ルールの実装元は一つ、またはゼロでなければなりません。

ツール

ツール	回答する内容
warda_wallet	ウォレット全体の概要：アドレス、上限、支出可能額、許可リスト。
warda_grant_authority	このエージェントは今、何を支出できますか？
warda_grant_address	このグラントはどこにありますか？
warda_check_spend	この支払いは受け入れられますか？受け入れられない場合、その理由は何ですか？
warda_check_delegation	この子グラントは、適切に範囲を狭めたものですか？
warda_build_spend	この支払いに署名するバイト列。
warda_build_delegation	このグラントを分割するために署名するバイト列。
warda_build_settlement	子グラントを親グラントに戻すために署名するバイト列。
warda_build_exit	このグラントを失効させる、または期限切れ後に回収するために署名するバイト列。
warda_recover_grant	グラントを使用したトランザクションから、グラントを再発見します。

この4つのツールはしばらく欠けていました。この欠落がどのようなものだったか、明確にしておく価値があります。エージェントは支出可能な内容を尋ねて支出を構築できても、グラントのライフサイクルにおけるそれ以外のことには何もアクセスできませんでした。不正行為に気づいた監視ツールは報告を提出できても、それに対処できませんでした。記録が古くなった呼び出し元には、グラントに戻る方法がまったくありませんでした。

「ウォレット」と呼びながら、それが何ではないかを説明します

warda_wallet は開発者になじみのある言葉を使います。そしてツールがそう呼んだ瞬間、次に当然あると思われるフィールドは残高です。**このサーバーにはノードがありません。**返される数値はすべて、渡された記述子に基づいているため、オンチェーン残高は意図的に含まれていません。単に省略するのではなく、レスポンス内でそのことを明示します。古くなった記録から算出した残高は、このプロトコルで繰り返し問題になっており、最も成功しているように見える失敗だからです。

テストではこの欠落を検証します。したがって、後からこのサーバーにノードを持たせるかどうかは、誰かが判断することであり、オートコンプリートが勝手にそうすることはありません。

このツールは warda_grant_address と warda_grant_authority を組み合わせるだけで、新たな計算は行いません。すべてのフレームワークが少しずつ異なる方法で組み立てるはずだった2つの呼び出しについて、会計処理の実装をもう1つ増やす必要はありません。

グラントの所在と、それが変わり続ける理由

グラントのアドレスは状態のハッシュなので、支出や委任のたびに変わります。昨日のアドレスには、今日になると何も残っていません。また、空のアドレスと、一度も資金が入ったことのないグラントは見分けがつきません。これはあらゆる統合でつまずく唯一の事実です。そのため warda_grant_address は、その疑問に直接答えるために存在し、すべてのビルダーはグラントが次に到達する場所を返します。

失ったグラントを見つける

Kaspa の P2SH では、コベナントスクリプトを、それを使用するすべてのトランザクションの署名スクリプト内に平文で含める必要があります。そうしなければ、ネットワークはハッシュを検証できません。また、グラントの状態は、既知のオフセット位置でそのスクリプトに挿入されます。そのため、使用者が意図したかどうかにかかわらず、すべての支出で使用されたグラントが公開されます。warda_recover_grant はその情報を読み取り、グラントが現在ある場所までたどります。

これがなければ、グラントにアクセスできるのは誰かのディスク上の記録を通じてだけです。記録を失えば、コインはオンチェーンで完全に有効でありながら、単にアクセスできなくなります。上限がコンセンサスに存在することを主張するプロトコルなら、グラントの復旧可能性をファイルシステムに委ねるべきではありません。

決済と、単に待つこととの違い

子への付与が期限切れになると、残高は本人、つまり人間に戻ります。子が決済されると、未使用分は親エージェントの予算に戻り、親には子が実際に使用した分だけが請求されます。この違いこそが決済の存在する理由です。タスクの途中にいるエージェントは、所有者に戻った資金を使えません。

warda_build_settlement は、意図的に統合せず、2 つのダイジェストを返します。親側のものは親のエージェントキーで署名され、子側のものは失効キーで署名されます。付与をまとめることは、その付与を失効させることだからです。サブエージェントが自分で選んだ条件で、自身の付与を終了できてはなりません。

オンチェーンの情報からは導き出せない数値が 1 つ必要です。それは、その子を追加する前の親のリザーブルートです。リザーブはハッシュチェーンであり、1 つを取り出すには、そのプリイメージを指定する必要があります。warda_build_delegation はこの値を parentReserveRootBefore として返します。必ず保持してください。

warda_build_spend は、アドバイザリ判定が否を示す場合でも、トランザクションを構築し、判定も併せて報告します。この方針は意図的なものです。厳しすぎるローカルルールによって、チェーンが受け入れる支払いを妨げてはなりません。拒否すれば手数料がかかりますが、妨げると能力が失われます。

ただし、許可リストにない受取人は例外で、完全に拒否します。その受取人をツリーに配置する証明は存在しないため、有効なトランザクションはありません。借用した証明を捏造すると、コベナントによる拒否が、リストにない受取人ではなくツリーの不具合に見えてしまいます。

接続方法

{
  "mcpServers": {
    "warda": {
      "command": "npx",
      "args": ["-y", "@warda_protocol/mcp"]
    }
  }
}

バイト列の生成元

warda_build_spend は @warda_protocol/kaspa を通じて組み立てます。これは、testnet-10 で支払いを実行したものと同じ Rust の処理経路で生成された参照トランザクション golden-spend.json と照合されています。mcp/test/build.test.ts が最後の差異を検証します。エージェントフレームワークで使う方法と同じように、KAS を小数表記し、受取人を名前で指定して同じ付与を記述し、結果がバイト単位で完全に一致することを求めます。

2 つの語彙の間には、10 進数パーサー、SDK とは異なるコードで構築された Merkle ツリー、フィールド順で配置された構造体という 3 つの要素が介在するため、これは重要です。これらはいずれもルールではないため、支出を誤って許可することはありません。しかし、どれもチェーンが拒否するバイト列を、気づかれないまま生成する可能性があります。そしてそれが起きるのは、実際のお金が関わるときだけです。

まだ実装されていない機能

チェーンへのアクセスはありません。 サーバーは付与の現在の UTXO を検出できないため、呼び出し側が渡す必要があります。付与のアドレスは支払いのたびに変わるため、古い UTXO は見つからず、そのまま処理されません。（@warda_protocol/kaspa が検出できます。NodeClient.open はノード URL、URL のリスト、または Kaspa Resolver を受け取り、誤った応答を返すノードは拒否します。）

ブロードキャストには対応していません。 構築した支出は通常のトランザクションなので、すでに利用しているノードクライアントで送信してください。

テンプレートをパラメーターにしていないのは意図的です。 テンプレートはディスクから読み込まれます（パスは WARDA_TEMPLATE で上書きできます）。呼び出し側から渡されるテンプレートは、このプロトコルで最も脆弱な攻撃対象です。テンプレートを差し替えると、すべてのアドレスが誤ったものになり、付与は誰にも使用できないスクリプトに支払われます。