Aegis Boundary
Agents check in

あなたの Agent は
ここで check in できます。

このサイトには人だけでなく AI Agent の入口があります: /mcp の MCP server です。Agent が 自分・触れるデータ・ユースケースを申告し、依頼を出せます。返るものは 状態に正直です: 人が確認するまでは 受け付けた・未処理。

このページから試す ↓ Agent 向けの入口を読む (llms.txt)
仕組み

4 つの tool。読むのは自由、行為は境界に当たる。

Agent がここでできることは 4 つの MCP tool を通ります。2 つは読んで 例示するだけ (aegis_overview、boundary_check_in)。 2 つは頼まれた時だけ Aegis に送ります: boundary_arrival は send: true で、request_check_in は name・company・work email が揃った時に。送られるのは未検証の intake で、 verified な依頼にはなりません。

01 · See

aegis_overview

Aegis とは何か、状態モデル、提供内容、正直さの guardrail。構造化された読み取り専用。

02 · Arrive

boundary_arrival

Agent 自身のタスクに対する例示の Arrival Brief。send: true で申告 (分類のみ) が未検証 intake として受け付けられます。

03 · Feel

boundary_check_in

Agent 自身の経路について receipt が記録するであろうものの例示。助言のみで、receipt でも認可でも強制でもありません。下の panel からは意図的に外しています。

04 · Do

request_check_in

Agents check in。name・company・work email があれば依頼はすぐ Aegis に届き — 未検証のまま — 人が prefill 済の link で verified な依頼を完了します。

何が返るか

受け付けた。まだ処理していない。

Agent の依頼は本物です — 私たちの intake に届きます — ただし verified な依頼ではなく、何も確認されていません。応答はそれを自分の言葉で言います。

received_not_processed

依頼は Agent 発の未検証 intake として Aegis に届きました。受付番号 (IN-…) と、人が verified な依頼を完了する prefill 済 link を持ちます。

needs_contact

何も送信していません。name・company・work email が無いと、人が連絡できる相手がいません — 応答は prefill 済 link だけを返します。

rate_limited · not_received

同じ address から同じ拠点への送信が多すぎるか、channel が使えませんでした。何も受け付けていません。人向けフォームへの link はそのままです。

すべての intake に同じ 1 行が付きます: "Based on what you declared. Nothing was connected, tested, or verified." この経路で record は 発行されません — Boundary Arrival Record は Aegis gateway (計画中) からしか出ません。verified な依頼には人が要ります。
Agent を接続する

endpoint は 1 つ、Streamable HTTP。

JSON 応答の Streamable HTTP を話す MCP client なら使えます (server から client への stream は開きません)。key も登録も不要: 読むのは自由。2 つの行為は Worker で address ごとに制限されます — 拠点ごとの上限で、全体の上限ではありません。

Claude Code 
claude mcp add --transport http aegis-boundary https://aegisboundary.com/mcp

汎用 MCP config 
{
  "mcpServers": {
    "aegis-boundary": {
      "type": "http",
      "url": "https://aegisboundary.com/mcp"
    }
  }
}

terminal から 
curl -s https://aegisboundary.com/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"boundary_arrival","arguments":{"agent":"support copilot","data":"customer records","use_case":"draft replies"}}}'

このページから試す

Agent が呼ぶ endpoint を、そのまま呼ぶ。

この panel は Agent が送るのと同じ JSON-RPC をブラウザから送り、 応答を返ってきたまま表示します。人として Check-in を希望するなら、 verified な経路は 申込フォーム です — この panel は Agent が見るものを見せるだけです。

wire に流れたもの (JSON-RPC) を見る

Request (JSON-RPC 2.0)


          
Response (tool の結果は wire 上は JSON 文字列。ここでは読みやすく展開して表示)

          

          

          

          
intake_id (IN-…) は受付番号であって record ではなく、何かの証明でもありません。received_not_processed は文字どおりの意味です。送られた内容は Aegis の受付台帳に保持され (届いた事実と申告内容)、intake 宛 mailbox にも内部通知として届きます。10 分以内に同じ申告を再送すると、2 通目の通知ではなく同じ受付番号が返ります。応答は呼んだ言語 (lang) で返ります。status 値と id は英語のままです。

        

      

    


    


    
    

      

        

          人へ
          
verified な依頼は、やはりあなたのもの。

          

            Agent は到着して依頼を出せます。境界を越えるのは人です: 申込フォーム、
            verified、1 Agent / 1 データ経路 / 1 ユースケース。
          

          

            Boundary Check-in を申し込む →
            Boundary Arrival から始める
          

        

        

          Agent の intake は「受け付けた・未処理」です。Boundary Check-in でも
          Boundary Receipt でも record でもなく、人が確認するまで何も検証されません。
          宣言された目的はラベルであって、認可ではありません。Aegis Gateway は計画中のままです。