ステータス: 移行中であり、この README は古い形を説明しています。
AgentBridge は Claude-Code-to-Codex/Antigravity ブリッジとして始まり、以下に記載されたすべての内容は今日も動作します。現在は、サポートされている任意の CLI をオーケストレーター、他の任意の CLI をワーカーにできるよう一般化しており、ルーティングはハードコードされたモデル名ではなくユーザーごとのプロファイルで駆動します。
今後の方向性については
docs/architecture.mdとdocs/roles.mdを参照してください。進行中: プロバイダーアダプター層（src/providers/）、ルーティングプロファイル（src/profile/）、agentbridge initセットアップフロー。Cursor アダプターは存在しますが未検証です。そのフラグはインストール済み CLI から読み取ったものではなく、事前知識から書かれたもので、その旨がファイルの先頭に明記されています。移行が完了するまでは、以下のセクションを Codex と Antigravity のワーカーに関する正確な記述として扱い、docs を設計に関する正確な記述として扱ってください。
AgentBridge は /agentbridge … コマンド群をMCP プロンプトとして公開するため、prompts/list をサポートする MCP クライアントであれば、サーバー自体から同じコマンドを取得できます。ホストごとのコマンドファイルをインストールしたり同期したりする必要はありません。
ホスト | インストール | コマンド |
Codex CLI | MCP プロンプト経由、加えて | |
Claude Code | MCP サーバーを登録し、必要に応じて | MCP プロンプト経由 |
コマンド | 内容 |
| 作業の規模を把握し、計画・委任・検証・報告する |
| CLI を検出し、それぞれが動作することを確認して、ルーティングプロファイルを書き込む |
| 何がインストールされ、ロールがどうマップされているかを示す（推論なし） |
| 実際のスモークジョブで診断し、修正すべきことを示す |
| ルーティングを表示または再導出する（オプションで 1 ロールのみ） |
| 1 回限りの範囲を限定したリポジトリ調査を行う |
| 異なるモデルファミリーによる独立したレビューを行う |
| 中断した実行を再開する |
これらのコマンドの背後にある考え方は doctrine/ にあり、モデル名は一切使用しません。ロール毎にルーティングし、.agentbridge/profile.json はロールを、ユーザーが実際にインストールしているものへマップします。
Claude Code が作業を外部ワーカーとしての Codex CLI と Antigravity CLI（agy) に委任できる、ローカルな小型 stdio MCP サーバーです。すでにログインしている CLI セッションを使用するため、API キーは不要です。
Claude がオーケストレーターであり続けます。AgentBridge は意図的に単純な配管機構です。Claude の構造化されたリクエストをワーカーのプロンプトに変換し、CLI を実行し、コンパクトな構造化結果を返すだけです。
User
└─> Claude Code (orchestrator — decides what to delegate)
└─> AgentBridge MCP tool (codex_run / antigravity_run)
└─> codex exec | agy --print
└─> result
<─ structured MCP result
<─ Claude inspects the work and continuesRelated MCP server: agent-intern
クラウドサービスでも、Web UI でも、データベースでも、デーモンでも、ダッシュボードでも、ジョブキューでも、アカウントシステムでも、API キー管理でもありません。Claude Code が stdio 上で起動し、終了時に停止する 1 つの Node.js プロセスです。
Claude が codex_run または antigravity_run を、構造化されたリクエスト（goal、mode、model、effort、paths、contract、acceptance criteria…）とともに呼び出します。
AgentBridge は、それらのフィールドだけからワーカープロンプトを組み立てます。それ自体がモデルを実行することはありません — これは文字列の組み立てであって、推論ではありません。
書き込みスコープを確保し、git 作業ツリーをスナップショットし、引数の配列（shell: false）で CLI を起動します。
CLI の機械可読出力を解析し、ワーカーの最終結果（内部の推論は取り出さない）を抜き出し、git を diff して実際に何が変更されたかを判断し、コンパクトな JSON 結果を返します。
MCP 呼び出し 1 回 = ワーカーの試行1 回。AgentBridge は一切リトライしません。もう 1 回試行する価値があるかどうかは Claude の決定です。
Node.js | 20.10 以上（24.14 でビルド・検証済み） |
Codex CLI |
|
Antigravity CLI |
|
git | 任意だが強く推奨 — ない場合 |
AgentBridge は、Codex や Antigravity の認証情報を読み取ったり、コピーしたり、エクスポートしたり、変更したりしません。ログインした人間が行うのとまったく同じ方法で CLI を起動するだけです。
npm installnpm run buildnpm testテストスイートはすべてモックプロセスを使用するため、通常の npm test でモデルクォータは消費しません。
一度ユーザースコープで登録すれば、すべてのプロジェクトで使用できます。
claude mcp add --transport stdio --scope user agentbridge -- node D:\Code\Agentbridge\dist\index.jsターミナルから確認:
claude mcp listclaude mcp get agentbridge次に、Claude Code の中から /mcp を実行して確認します。agentbridge が接続済みとして表示され、codex_run・antigravity_run・bridge_status の 3 つのツールが見えるはずです。完全なヘルスレポートを得るには Claude に bridge_status を呼び出してもらいます。
AgentBridge を再ビルドした場合は、Claude Code を再起動するか /mcp からサーバーに再接続して、新しい dist/ を読み込んでください。
ワーカーは単一のプロジェクトディレクトリ内で実行され、そこにスコープされます。解決順は以下です。
AGENTBRIDGE_PROJECT_DIR、その次にレガシーの CLAUDE_PROJECT_DIR（Claude Code がエクスポートするもの）。
MCP クライアントが通知する最初の file:// ルート。
サーバプロセスの作業ディレクトリ。
bridge_status は、どれが使用されたかを報告します。
codex_runフィールド | 型 | 説明 |
| string | 必須 |
|
| 必須 |
|
| 必須 |
|
| 必須 |
| string[] | 最初に見てほしいファイル |
| string[] |
|
| string[] | ワーカーが変更してはならないパス |
| string | リポジトリにない背景情報 |
| string | 完全に合わせる必要のあるインターフェース・型 |
| string[] | |
| string[] | ワーカーへのコンテキスト — AgentBridge 自身が実行することはない |
| number | デフォルト 900、30〜3600 に制限される |
モデル。 3 つのスラッグが利用でき、それぞれが CLI にそのまま渡されます。
| 内容 |
| 最強の汎用エンジニアリングモデル |
| 深いブラウンフィールド / 既存コードベース特化型 |
| 経済的な高ボリューム向けワークホース |
エフォートマッピング（オーケストレーターのラベル → Codex の model_reasoning_effort）:
|
|
|
|
|
|
|
|
|
|
マッピングは全体にわたって完全かつ決定的です。Codex の ultra ティアは意図的に公開していません。一部のモデルだけが備えているためで、3 つのうち 2 つでしか機能してくれない 6 番目のラベルを加えると、ルーティングがモデル依存になるからです。
可用性. 起動前に AgentBridge は、リクエストされたモデルと effort を Codex CLI 自身のモデルカタログ（CODEX_HOME の models_cache.json）と照合します——ただのファイル読み取りであり、推論ではありませ。
モデルもある・effort もある → ジョブは実行される
モデルあり・effort なし → invalid_effort を返し、details.supported_efforts を添える
モデルなし → requested_model_unavailable を返し、details.available_models を添える
読み取れるカタログなし → 可用性は unverified であるという警告付きで、ジョブはとにかく実行される
何かが他の何かに置き換えられることは一切ありません。実現できないルーターングの決定は、静かに弱いモデルに落ちるのではなく、1 ステップで再ルーティングできる充分なメタデータを含む構造的なエラーとして返されます。
呼び出しは次のように構築されます:
codex exec --json --skip-git-repo-check -m <MODEL> -c model_reasoning_effort="<EFFORT>" \
-s <read-only|workspace-write> -C <PROJECT> -o <tmpfile> --color neverプロンプトは stdin でストリームされます。モデル・effort・sandbox は毎回渡されるため、~/.codex/config.toml に何が設定されていても、実行がそれを引き継ぐことはありません。
analyze と review は Codex の実際の read-only サンドボックスを使用します——書込みは単に控えさせるだけではなく、実際に妨害します。
antigravity_run同じスキーマで、以下が異なります。
フィールド | 型 型 | 説明 |
|
| 必須 |
|
| 任意、デフォルトは |
論理名は実行時に現行の agy models 一覧と照合して解決されます:
ラベル | エジョト出力 | 解決先（このマシンにおける） |
|
|
|
|
|
|
|
|
|
Antigravity は推論レベルを model id に組み込んでいるため、model + effort は単一の id に解決され、別の --effort フラグは送られません。この 2 つが矛盾することはありません。 extra high と max は、より軽いティアをひっそりと実行する代わりに invalid_effort を返します。
Antigravity は意図的に安価な Flash ティアに制限されています。agy が提供する Claude モデルはルーティング可能なラベルとして公開していません。Claude クラスの推測には、実際のサンドボックスと（Codex では）選択可能な effort を備えた Claude Code 自身か Codex を使ってください。
ラベルは、同じモデルのIDの順序付き候補リストを持ちます。インストール済みCLIがそれらのどれも提供していない場合、呼び出しはrequested_model_unavailableと、利用可能なモデルの完全なリストを添えて失敗します。別のモデルに黙ってフォールバックすることは決してありません。 解決されたIDは毎回の実行でwarningsにエコーバックされます。
構築される呼び出しは次のとおりです:
agy --print <PROMPT> --model <RESOLVED_ID> --output-format json \
--mode <plan|accept-edits> --add-dir <PROJECT> \
--dangerously-skip-permissions --print-timeout <N>s--disable-slash-commandsはimplementの実行時のみ追加されます。スラッシュコマンドの展開が無効になっている場合はCLIが--mode planを無視するため、両方を送信すると、Antigravityが提供する唯一の書き込みなし動作が黙って破棄されてしまいます。
bridge_status引数なし。モデルの推論は一切消費しません。--versionプローブ、agy models、1回のgit rev-parse、Codex CLI のモデルキャッシュの読み取りだけを実行します。
返す内容:
AgentBridgeのバージョン、プロジェクトディレクトリ（どのように解決されたかを含む）、node/プラットフォーム
git_verification — gitベースのfiles_changed / scope_violationsがここで機能するかどうか。機能しない場合、空のscope_violationsは問題なしという意味ではなく沈黙であり、warningsにその旨が示されます
codex.installed / version / path / auth
codex.model_status — モデルごと: available | unavailable | unverified、そのモデルに指定できるeffortラベル、CLIの生の推論レベル
codex.model_source — 可用性の情報元と、その情報の新しさ
antigravity.installed / version / path / auth、検出されたモデル、各論理ラベルとティアの解決結果、同じ3状態の形のmodel_status
antigravity.unsupported_efforts — Flashが受け取れないオーケストレーターラベル
アクティブなジョブとその書き込みスコープ
warnings
可用性が推測されることはありません。インストール済みのCLIが軽量な証明を提供しない場合は、どちらかに断言するのではなく、unverifiedになります。
認証情報や環境変数を返すことは決してありません。
{
"status": "success",
"provider": "codex",
"model": "gpt-5.6-luna",
"effort": "high",
"mode": "implement",
"duration_ms": 12345,
"exit_code": 0,
"summary": "...",
"files_changed": ["src/upload.ts"],
"scope_violations": [],
"tests_or_checks_run": ["npm test -- upload"],
"test_results": "12 passed",
"concerns_or_blockers": [],
"stderr_tail": "",
"warnings": []
}effortは両プロバイダーに存在します — Codexの推論レベル、またはモデルidにエンコードされた Flash tier です。files_changedとscope_violationsは、ワーカーの供述ではなく、AgentBridgeがgitから算出します。内部推論は破棄されます。summaryは16,000文字に制限され、先頭と末尾は保持され、カットされた場合はsummary_truncated: trueが設定されます。
失敗時も同じエンベロープ構造で、status: "failed"、errorカテゴリ、的確なアクションに導くmessage、そして利用可能な場合にはexit_code、stderr_tail、detailsオブジェクトを返します。
カテゴリ | 意味 |
|
|
| CLIがログインの問題を報告した — 自分で再度サインインする |
| 要求されたモデルは提供されていない。代替は行われなかった |
| effortラベルがサポートされる5つの値の範囲外 |
| 例: |
| 他のアクティブなワーカーが既に重なる書き込みパスを保持している |
| 与えられたパスがプロジェクトルートから外れた、またはワーカーがスコープ外に書き込みをした |
| ワーカーが時間を超えた。そのプロセスツリーは終了された |
| 非ゼロの終了コード、または |
| CLIの機械可読出力を解析できなかった |
安くて速い分析:
{ "tool": "codex_run",
"goal": "Explain how session refresh works and where it can race.",
"mode": "analyze", "model": "gpt-5.6-luna", "effort": "light",
"relevant_files": ["src/auth/session.ts"] }本格的な実装、最大の推論、厳密なスコープ:
{ "tool": "codex_run",
"goal": "Make the uploader retry 502s with exponential backoff.",
"mode": "implement", "model": "gpt-5.6-sol", "effort": "max",
"allowed_paths": ["src/upload.ts", "tests/upload.test.ts"],
"no_touch": ["src/auth"],
"contract": "export function upload(f: File): Promise<Result>",
"acceptance_criteria": ["Retries up to 3 times", "Existing callers unchanged"],
"tests": ["npm test -- upload"] }スコープが重ならない2つのCodexワーカー — これらは同時に実行されます:
{ "tool": "codex_run", "mode": "implement", "model": "gpt-5.6-sol",
"effort": "high", "allowed_paths": ["src/api"], "goal": "..." }
{ "tool": "codex_run", "mode": "implement", "model": "gpt-5.6-luna",
"effort": "medium", "allowed_paths": ["src/ui"], "goal": "..." }安価な機械的作業(アプリケーションの定型処理など)には Antigravity:
{ "tool": "antigravity_run", "goal": "Summarise every exported symbol in src/lib.",
"mode": "analyze", "model": "Gemini Flash 3.7", "effort": "light" }
{ "tool": "antigravity_run", "goal": "Build the settings page from design.png.",
"mode": "implement", "model": "Gemini Flash 3.7", "effort": "high",
"allowed_paths": ["src/pages/settings"] }implementは**allowed_pathsを必要とします**。パスはプロジェクトルートを基準に正規化され、ルートを脱出するもの（..、他のドライブ、他所への絶対パス）はプロセス開始前に拒否されます。
アクティブなimplementジョブは、その書き込みスコープをメモリに保持します。アクティブなジョブとスコープが重なる新しいジョブは、ユーザーに警告されます。
Wait—"はscope_conflictで拒否されます。重なり合わないスコープは並行実行されます — 無関係な作業が直列化されることはありません。
analyzeとreviewは何も予約しません。ブロックすることもされもせず、一切ブロックされません。
ファイルスコープの保護は違反を検出して報告します。ワーカーをそれぞれのツリーにサンドボックス化するものではありません。Codexのimplementワーカーは、プロジェクト全体にworkspace-writeで実行されるため、allowed_pathsの外に書き込むこともできます — AgentBridgeはそのようなすべてのファイルをscope_violationsに列挙し、successからのステータスを引き下げ、そのことをはっきりと伝えます。
何も自動的にリバートされません。 ワーカーが開始する前にすでに変更されていたファイルをリバートすると、あなた（またはClaude）が既に行った作業が壊れてしまいます。検出と誠実な報告がV1の契約であり、git-worktree の分離は意図的にスコープ外です。
attribution は事前状態に対して細心の注意を払います。実行前に既に dirty で、その後もバイト単位で同一のファイルは、ワーカーのせいにされません。尐ビブラウド比較は porcelain ステータスとコンテンツハッシュで行い、コミットされたファイルは HEAD 移動 diff で拾われます。
プロセスは**引数式配列とshell: false**で起動します — 補完されたコマンド文字列を決して使わしません。引数中のシェルメタ文字はリテラルのままです。
Windowsの.cmd/.ps1ランチャー（Nodeがシェルなしでの起動を拒否するもの）は、実際のNodeエントリスクリプトに解決され、node <script>として実行されるため、shell: trueは不要です。
プロンプトはCodexにstdin経由で渡されます。大きすぎるAntigravityプロンプトは一時ファイルに書いてパスで参照されます。どちらもWindowsの32,767文字コマンドライン制限に達しません。
testsはワーカーのためのコンテキストです。AgentBridgeがそれを実行することはなく、AgentBridgeが実行するコマンドになるようなMCP引数はどこにもありません。
プロジェクトルートを出るパストラバーサルは拒否されます。
タイムアウトはプロセスツリー全体を終了します: Windowsではtaskkill /T /F、POSIXでは3秒の猶予を設けてからプロセスグループへのSIGTERMがSIGKILLへエスカレーションします。このエスカレーションは意図的に直接の子プロセスの終了を超えて続行されます。そのタイミングこそ、子孫がまだ実行中かもしれないからです。これはベストエフォート — Node は Windows Job Object を公開しないため、taskkill自体が起動できない場合は直接の子だけにしか到達できません。
出力バッファは制限されており（ストリームあたり8 MB）、UTF-8は再構成後にのみデコードされるため、マルチバイト文字が分割されることはありません。
ログにはジョブのメタデータのみが記録されます。トークンや環境変数は記録されず、プロンプトと出力はAGENTBRIDGE_DEBUG=1の場合のみ。
AgentBridge が守ってくれないもの: ワーカーは実際のコーディングエージェントで、あなたの権限で実行されます。implementモードでは独自のツールを通じてリポジトリコマンドを実行できます。allowed_pathsはそれに合わせて範囲を設定してください。
AgentBridgeはワーカーが終了した後、サンドボックスの外でプロジェクト自身のチェックを自分で実行し、実際の出力を verification に返します:
"verification": [
{ "command": "npm run typecheck", "ok": true, "exit_code": 0, "timed_out": false, "duration_ms": 4120, "output_tail": "..." },
{ "command": "npm run test", "ok": false, "exit_code": 1, "timed_out": false, "duration_ms": 8830, "output_tail": "..." }
]verify_commands — モードにかかわらず、この通りのコマンドを実行します。
implementモードの場合は省略 — AgentBridgeははpackage.jsonを読んで、typecheckとtestのスクリプトが存在すれば実行します。build、dev、start は自発的には実行せず、明示的に依頼してください。
skip_verification: true — 何も実行しないで、ワーカーの報告をそのまま信頼します。
コマンドはシェルなしで実行されるため、引用符で囲まれていない|、&&、;、>、バッククォートは半端に実行されるのではなく拒否されます。チェックの失敗はerror: "verification_failed"としてセットされ、successはpartialに下がるため、テスト成功を主張するワーカーがテスト自体より上に行くことはありません。
tests_or_checks_runとtest_resultsは、検証が行われたときにAgentBridgeが実際に実行したものを報告します。検証が行われなかった場合のみワーカーの申告にフォールバックします。
コマンドはリポジトリ由来なので、ブリーフが間違ったランナーを指し示してもAgentBridgeがそのランナーを実行することはありません。テストスクリプトがnode --import tsx --testのリポジトリは、ブリーフが何と言おうと、そのコマンドで検査されます。
変数 | 用途 |
| プロジェクトディレクトリ。ホストに依存し、優先される |
| レガシー名。 引き継がれ、Claude Code が設定する |
| サニタイズされたプロンプトと出力をログに記録する |
| ログの場所（デフォルト |
| 実行すpath of Codex CLI（明示的パス指定） |
|
|
| Codexサンドボックスを固定する: |
| Windowsサンドボックスバックエンド（デフォルト |
AGENTBRIDGE_CODEX_SANDBOX=auto は、analyze/review には read-only、implement には workspace-write を使います — 実装モードでは — しかし Windows では、サンドボックス化された Codex はサブプロセス出力を取得できず（パイプ stdio 上で spawn EPERM）、npm スクリプト、テストランナー、バンドラーはすべてこれを行うため、読み取りと編集はできますが、テストランナー、型チェッカー、ビルドを実行することはできません。これは設定で変更できないCodexの制限であり、implementジョブはワンショットのプローブで確認できた場合にdanger-full-accessにフォールバックし、" warnings, その旨が告知されます。Analyze と review は強制された read-only の境界を維持します。Windowsで壊れたサンドボックスヘルパー（helper_unknown_error: apply deny-read ACLs）で実行に失敗した場合、AgentBridgeはそのジョブを一度だけdanger-full-accessで再試行し、残りのプロセス中はその決定を覚えておき、境界が強化されなかったことを各結果に警告として付与します。それ以外の要因でフォールバックがトリガされることはなく、AgentBridgeを再起動すれば実際のサンドボックスを再試行します — したがって固定されたCodexリリースは自動的に復元します。macOSとLinuxはプローブ、リトライ、フォールバックを一切行いません。
ログはジョブごとにJSONの1行として保存されます。タイムスタンプ、ジョブID、プロバイダー、モデル、effort、モード、プロジェクト、実行時間、終了コード、エラーカテゴリ。
executable_not_found — CLIが Claude Code が子プロセスに PATH を渡したものに含まれていません。 同じシェルで codex --version / --physical -- を確認するか、AGENTBRIDGE_CODEX_BIN / AGENTBRIDGE_AGY_BIN を設定してください。
authentication_required — CLIのセッションが期限切れです。ターミナルで codex login (Codex) または agy でサインインし直してください。AgentBridgeには意図的に、認証情報に触れないため、これを修復する機能はありません。
requested_model_unavailable — モデルリストが変更されたか、インストール済みのCLIがそのモデルを提供していない可能性があります。実際に提供されているモデルを確認するには bridge_status（または agy models）を実行してください。エラーの details にはすでにその情報が含まれています。AgentBridge は、異なるモデルを静かに実行するのではなく、意図的にここで失敗します。プロバイダーがモデルIDを変更した場合は、src/models/antigravity.ts のそのラベルの候補リスト（または src/models/codex.ts の CODEX_MODELS）に新しいIDを追加して、再ビルドしてください。
output_parse_failed — CLI が機械可読な出力形式を変更した可能性があります。結果内の details.stdout_head を確認し、parseCodexEvents / parseAgyOutput と比較してください。
CLI アップデート後 — テストを再実行し、次にライブスモークチェックを実行してください:
SMOKE_LIVE=1 node scripts/smoke.mjsこれは実際の MCP セッションを駆動し、各ワーカーの最も安価な構成を実行します。SMOKE_LIVE=1 がない場合、ハンドシェイクと bridge_status のみを実行し、何も消費しません。
files_changed が常に空 — プロジェクトディレクトリが git ワーキングツリー内にありません。結果内の警告にその旨が示されています。変更検証には git が必要です。
/mcp の下に何も表示されない — 登録されたパスが dist/index.js（src/ ではなくビルド済み）を指していることを確認し、再ビルド後に Claude Code を再起動してください。
src/
index.ts stdio entry point
server.ts MCP server, tool schemas, dispatch
config.ts project-dir resolution, timeout clamping
logging.ts JSONL job log (stderr only, never stdout)
parse.ts worker-envelope parsing, summary capping
types.ts
cli/
resolve.ts PATH lookup + Windows shim unwrapping
detect.ts version probes, agy model listing, auth heuristics
codex-catalogue.ts zero-inference Codex model availability + effort capability
codex-sandbox.ts sandbox policy decision and helper-failure detection
models/
codex.ts effort map, argv construction
antigravity.ts logical→real model resolution, argv construction
process/
runner.ts shell-free spawn, bounded output, tree kill
prompts/
worker-prompt.ts structured request → worker prompt
scope/
paths.ts normalisation, traversal rejection, overlap
locks.ts in-memory write-scope registry
git-state.ts snapshot/diff file attribution
tools/
codex.ts antigravity.ts status.ts common.ts
tests/ 252 tests, mocked processes, no quota used
scripts/smoke.mjs real MCP end-to-end checkDelegate a task to the Antigravity CLI (agy) running as an external worker, using your existing Antigravity login (no API key). The logical model name and effort tier are resolved against the installed CLI's live model list and are never silently substituted. Returns the worker's final result plus git-verified files_changed and scope_violations. One call = one attempt; AgentBridge never retries on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the worker must accomplish. Be specific and self-contained. | |
| mode | Yes | analyze/review are read-only investigations; implement makes changes and runs checks. | |
| model | Yes | Antigravity model to run. | |
| tests | No | Tests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute. | |
| effort | No | Flash reasoning tier, selected via the model id. light=search/extraction/docs/simple edits, medium=default coding, debugging, review, refactors, high=hard reasoning, architecture, visual/multimodal work. Defaults to medium. 'extra high' and 'max' do not exist here — route those to Codex. | |
| context | No | Background the worker needs but cannot infer from the repository. | |
| contract | No | Interfaces, types, or API shapes the worker must conform to exactly. | |
| no_touch | No | Project-relative paths the worker must not modify. | |
| allowed_paths | No | Project-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected. | |
| relevant_files | No | Project-relative files the worker should look at first. | |
| timeout_seconds | No | Wall-clock limit for the worker process. Default 900s, clamped to 30-3600s. | |
| acceptance_criteria | No | Conditions that must hold for the job to be considered done. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and does an excellent job: it discloses authentication requirements ('using your existing Antigravity login (no API key)'), resolution behavior ('never silently substituted'), return contents ('git-verified files_changed and scope_violations'), and retry policy ('AgentBridge never retries on its own'). No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences, each earning its place: delegation mechanism, resolution policy, return value summary, and retry semantics. It is front-loaded with the primary action and free of redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and no annotations, the description covers key operational context: auth, resolution, returns, and retry policy. It lacks guidance on when to prefer this over codex_run and what happens if the CLI is unavailable, but the 100% schema coverage compensates for parameter-level details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description does not add new parameter-level semantics beyond what the schema already provides; it only references the model/effort resolution vaguely, which is adequately covered in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delegate a task to the Antigravity CLI (`agy`) running as an external worker.' It specifies the verb, resource, and distinctive auth behavior (no API key). However, it does not explicitly differentiate from sibling tools like codex_run, even though the Antigravity-specific naming implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (codex_run, bridge_status). It mentions 'One call = one attempt' and 'never retries' as behavioral facts, but does not state usage conditions, prerequisites, or when to choose a different tool. Relevant routing advice (e.g., 'extra high' → Codex) is buried in the parameter descriptions, not the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report AgentBridge health: version, project directory, whether git-based scope verification will work here, whether the Codex and Antigravity CLIs are installed, their versions and sign-in state, per-model availability (available | unavailable | unverified) and the efforts each model accepts, resolved Antigravity model ids, active jobs, and warnings. Consumes no model inference — availability comes from each CLI's own catalogue, and is reported as unverified rather than guessed when it cannot be established cheaply. Never returns credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description fully carries the transparency burden and excels: it discloses a no-inference cost guarantee, an explicit epistemic honesty policy ('reported as unverified rather than guessed'), and a security guarantee ('Never returns credentials'). These behavioral traits go well beyond what the empty schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three prior sentences, each earning its place: scope, then cost/accuracy behavior, then security. The second sentence is list-heavy but necessary since no annotations or output schema exist — the description is the sole documentation. Slightly long but never wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 0-param, read-only tool with no annotations and no output schema, the description is the only source of truth and covers all critical operations: exact contents of the report, inference cost (none), accuracy semantics (unverified vs guessed), and credential safety (never). Nothing material is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline of 4 per the rubric applies. The description adds no conflicting param info; the only implied input is the health-report scope itself, which is irrelevant for a no-arg call. No compensation needed for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb+resource ('Report AgentBridge health') and exhaustively enumerates the report's scope: version, directory, CLIs, model availability, model ids, jobs, warnings. This specificity clearly delineates it from siblings codex_run/antigravity_run, which are execution-oriented, making the health/introspection function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The health/introspection framing implies pre-flight or diagnostic use (checking sign-in state, git verification, per-model availability) with clear context. However, no explicit exclusions or named alternatives appear in the description; sibling distinction is inferred from context rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate a task to the Codex CLI running as an external worker, using your existing Codex login (no API key). Model and reasoning effort are chosen per call and never inherited from global Codex config. Returns the worker's final result plus git-verified files_changed and scope_violations, and — unless skipped — a verification block holding the real output of the project's checks, which AgentBridge runs itself. One call = one attempt; AgentBridge never retries on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the worker must accomplish. Be specific and self-contained. | |
| mode | Yes | analyze/review are read-only investigations; implement makes changes and runs checks. | |
| model | Yes | Codex model to run, passed to the CLI verbatim. gpt-5.6-sol is the strongest general engineering model, gpt-5.6-terra the deep brownfield/existing-codebase specialist, gpt-5.6-luna the economical high-volume workhorse. Availability is checked against the installed CLI's own model catalogue; an unavailable model fails with requested_model_unavailable and is never substituted. | |
| tests | No | Tests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute. | |
| effort | Yes | Reasoning effort: light->low, medium->medium, high->high, 'extra high'->xhigh, max->max. | |
| context | No | Background the worker needs but cannot infer from the repository. | |
| contract | No | Interfaces, types, or API shapes the worker must conform to exactly. | |
| no_touch | No | Project-relative paths the worker must not modify. | |
| allowed_paths | No | Project-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected. | |
| relevant_files | No | Project-relative files the worker should look at first. | |
| timeout_seconds | No | Wall-clock limit for the worker process. Default 900s, clamped to 30-3600s. | |
| verify_commands | No | Commands AgentBridge runs itself in the project directory after the worker exits, e.g. ["npm run typecheck", "node --import tsx --test"]. Their real output comes back in `verification`. Run without a shell, so no pipes, redirection, or `&&`. Omitted in implement mode, AgentBridge derives them from the project's own `typecheck` and `test` scripts. | |
| skip_verification | No | Set true to skip AgentBridge's own checks for this job. The result then carries only the worker's account of whether the change works. | |
| acceptance_criteria | No | Conditions that must hold for the job to be considered done. | |
| verify_timeout_seconds | No | Wall-clock limit for each verification command. Default 300s. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: authentication via existing login, per-call model/effort choices, git-verified files_changed and scope_violations, the verification block auto-run by AgentBridge, skip_verification semantics, and the no-retry policy. It also mentions error behavior (requested_model_unavailable) in schema but the main description adds substantial context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value, covering purpose, authentication, behavioral semantics, and verification details. It is front-loaded with the core action and flows logically. Slightly long but appropriate for a 15-parameter tool; no fluff detected.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 params, no output schema), the description is remarkably complete. It explains the verification process, git-verified outputs, retry behavior, and model availability handling. It does not detail return value structure, but since there is no output schema, the description covers the essential outcomes (result, files_changed, scope_violations, verification block) sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond what schema provides; it does note that model is passed verbatim and verification runs without a shell, but these are already in schema descriptions. No extra compensation needed, but also no significant enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delegates a task to the Codex CLI external worker, specifying the resource (Codex CLI) and the verb (Delegate). It distinguishes from siblings by naming Codex explicitly, and includes details like 'no API key' and 'one call = one attempt' that set it apart from antigravity_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus antigravity_run or bridge_status. It mentions configuration behavior (model/effort per call, no global inheritance) and retry policy, but fails to state conditions for selecting this tool over alternatives. This is a gap given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0antigravity_runbridge_statuscodex_runScored across 3 tools
Each tool has a clearly distinct purpose: codex_run and antigravity_run target different external CLIs, and bridge_status is the health/status reporter. There is no meaningful overlap or ambiguity between them.
The two worker tools follow a consistent <cli>_run pattern, while bridge_status deviates by using a noun instead of a verb. This is a minor inconsistency in an otherwise predictable naming scheme.
Three tools is well-scoped for a bridge server: one for each external worker and one for status. Every tool earns its place and the count feels appropriate for the server's purpose.
The core workflows of delegating to either CLI and checking bridge health are covered. Minor gaps exist around job lifecycle management (e.g., listing or canceling active jobs), but these are not critical to the stated purpose.
Orbit is an MCP server that gives your AI agents a 4000+ tools, a shared memory brain and a live dashboard OS. Every agent reads active decisions, logs outputs to a searchable vault, and reports status in real time. 2-minute setup via MCP; works across Claude, ChatGPT, Codex, Cursor, Gemini, and Manus. Finally Agents work, agents that grow your business and bring you customers. https://orbitagents.xyz
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
