mcp-bifrost

MCP-Bifrost

安価なモデルで200個のメソッドを書き換えます。結果の1行たりとも高価なモデルのコンテキストを通さず、コンパイルできないものはディスクに一切書き込みません。

MCP サーバーは、オーケストレーションモデルによってすでに分析・分割されたコード作業を受け取り、各言語のパーサーで対象ブロックを正確に抽出し、より安価なワーカーモデルに書き換えを委任して、結果を検証し、アトミックに適用します。そして、一連の作業をオーケストレーターのコンテキスト外に記録します。

判断するのは頭脳、タイピングするのは筋肉です。Bifrostはその間をつなぐ神経であり、壊れたものがディスクに書き込まれないことを保証する役割も担います。

以下の例では、頭脳にClaude、筋肉にDeepSeekを使っています。これはたまたま手元にあったモデルにすぎません。どちらも必須ではありません。7Bモデルを自分のマシンで動かすほうが興味深い選択肢になり得る理由については、ワーカーをご覧ください。

---

なぜ

LLMで大規模なコードベースを編集する際の本当のボトルネックはひとつであり、知能ではありません。コンテキストです。4,600行のファイルを読み、そのうち30行を変更するだけでも、オーケストレーターのコンテキストウィンドウは二度と使わないテキストで消費されます。

Bifrostの前提は、コーディングの機械的な部分、つまり置き換えテキストの作成には、高価なモデルは必要なく、そのコンテキストを通す必要もないということです。

	オーケストレーターがすべて実行	Bifrost経由
202メソッド × 約800トークン	約161,000トークン — コンテキストウィンドウを超過	約15,000トークン

率直に言えば（RF-4をご覧ください）、小さな編集を1件行う場合、節約効果は確かにありますが、控えめです。通常、オーケストレーターは何を変更するか指示するために、いずれにせよコードを読む必要があるからです。桁違いの効果が得られるのは、大量のシンボルに対する変換で、何も読まずに指示を書ける場合です。

Bifrostは、このユースケースのために作られています。「このバグを直して」ではありません。

また、ログに表示される数値は反実仮想です。 このリポジトリのテストスイートは、Bifrost自体を通じて作成されました。1,608バイトの指示から97,909バイトが適用され、計算式では61倍と評価されます。実際の節約量はゼロでした。ブロックはワーカーではなくオーケストレーターが作成しており、そのバイトはすべてBifrostに渡される前に消費されていたためです。ログが記録するのは境界を通過した量であり、どこで書かれたかではありません。具体例は§11にあります。意図的に都合の悪い内容のまま掲載しています。

---

使用すべきでない場合

• 探索的な作業。「これがクラッシュする原因を探して」という指示は、Bifrost が実行できるものではありません。作業を始める前に、対象のシンボルを把握する必要があります。
• **小規模な編集を 1 件だけ行う場合。**トークン数の節約はわずかで、その点は明記しています（RF-4）。エージェントの通常の編集ツールを使用してください。
• **レイテンシが重視されるループ。**DeepSeek での測定では、ブロックあたり約 2.6 秒です。
• **PHP または Python 以外のコード。**言語を追加するにはコアを書き換えるのではなく、パーサーアダプターを作成しますが、現時点では対応していません。
• ある編集の形が別の編集の結果に左右される、ファイルをまたいだリファクタリング。patch_group が提供するのはアトミック性であり、順序制御ではありません。
• **何かが壊れたことを検知する方法がないコードベース。**ここにある各ゲートが確認するのは形式であり、意味を理解するものはありません。

Aider、Serena、fast-apply モデルとの使い分けや、それらのほうが優れている点については、docs/comparison.md を参照してください。

---

仕組み

you ──▶ Claude Code ──▶ MCP-Bifrost ──▶ worker model
         analyses,        parses,          writes one
         splits work      validates,       isolated block
                          applies, logs
                              │
                              ├──▶ source file (atomic splice)
                              └──▶ .bifrost/history.db

オーケストレーターが対象と方法を決定します。ワーカーは何も決定しません。ディスクに触れられるのはサーバーだけであり、すべてのゲートを通過するまで処理を拒否します。

検証ゲート

ゲート	チェック内容	デフォルト
0 — オフセット	ディスク上のブロックが、ワーカーに送信したものとバイト単位で一致する	オン
1 — 構文	再構築したファイルが php -l / ast.parse() を通過する	オン
2 — 単一シンボル	返されたブロックが定義するシンボルは 1 つだけ。クラスは、その内容にかかわらず 1 つとして数える	オン
3 — 実質的な内容	呼び出し、変数、制御キーワードが何も通知されずに消えていない	オフ

デフォルトでオンなのは 4 つではなく、3 つです。実質的な内容をチェックするゲートは粗い正規表現チェックで、キャリブレーション中に一度も発動しませんでした。正常なパッチを拒否するゲートは、まだ有効化されていないゲートより厄介です。一括作業の前に substance_gate=True を指定して有効にしてください。

対象範囲外のバイトを比較する「ペリメーターチェック」は仕様化され、実装されましたが、その後削除されました。サーバーはファイルを original[:start] + block + original[end:] として再構築するため、対象範囲外は構造上保持され、このチェックが失敗することはありません。キャリブレーションでもこれが確認されました。このゲートは 9/9 と報告しましたが、3 つのファイルは構文エラーのある状態で残されました。RF-1 を参照してください。

ロールバック

Git はすでにコンテンツアドレス可能なデータベースなので、そのように利用します。各パッチの前に git hash-object -w を実行すると、ログに記録される blob SHA が得られます。元に戻すには git cat-file blob を使います。重複排除と圧縮は自動で行われ、変更のある作業ツリーでも動作します。独自のスナップショット形式を保守する必要はありません。

---

ワーカー

DeepSeekが手元で利用できたため、このリポジトリの数値はすべてDeepSeekを使って測定しています。これは必須条件ではなく、おそらく最も興味深い実行方法でもありません。

ワーカーの役割は意図的に限定されています。切り離されたブロックと1つの指示を受け取り、1つのブロックを返します。ファイルを選んだり、変更を計画したり、編集する内容を決めたり、コードベースのほかの部分を見たりはしません。これは7Bのコーディングモデルでもこなせるタスクです。そして、弱いワーカーのミスがディスクに反映されてからではなく、その前に検出されるように、まさにゲートが設けられています。

だからこそ、ローカルで使う場合のほうが有力です。

• コードがマシンの外に出ることはありません。 プロプライエタリなコードベースでは、これは好みの問題ではなく前提条件です。
• この用途でのコストはゼロになります。 何百ものブロックを1回の実行で処理することが、例外ではなく通常の規模となる用途です。
• 必要なコンテキストはごくわずかです。 ファイル全体ではなく、1つのメソッドです。8kのコンテキストウィンドウで十分です。必要以上の情報をワーカーに見せないことが、設計の根幹です。
• 出力はすべて解析され、構文チェックと差分確認を経てから有効とみなされるため、弱いワーカーでも問題ありません。 ブロックの出力が不適切でも、ファイルが壊れるのではなく、再試行が必要になるだけです。

最後の点こそが、本当の論拠です。出力を信頼できず、手作業での確認にコードを書く以上のコストがかかるため、小規模なローカルモデルにコード生成を任せるのは、通常は得策ではありません。Bifrostの答えは、確認作業は機械的に行えるため、マシンに任せられるということです。

OpenAI互換のエンドポイントであればどれでも動作します。Ollama、llama.cppのサーバー、LM Studio、vLLMなどです。

"env": {
  "BIFROST_WORKER_BASE_URL": "http://localhost:11434/v1",
  "BIFROST_WORKER_MODEL": "qwen2.5-coder:7b"
}

デフォルト以外のエンドポイントを使う場合、キーは不要です。

ワーカーの互換性

ローカルモデルはまだ測定していません。 エンドポイントは設定可能で、プロトコルは一般的なOpenAI互換のチャット補完ですが、このリポジトリは測定していないことを謳いません。自分たちに有利な内容であっても同様です。

測定ツールは用意されています。エンドポイントを指定して実行してください。

BIFROST_TARGET=/path/to/your/codebase \
BIFROST_WORKER_BASE_URL=http://localhost:11434/v1 \
BIFROST_WORKER_MODEL=your-model \
python3 calibratge/calibra.py --cases 9

ワーカー	有効なJSON	バイト単位で一致（同一性タスク）	行の欠落なし	フェンスなし	レイテンシ
DeepSeek（deepseek-chat、API）	9/9	3/3	3/3	9/9	2.6 s
ここに使用するモデルを記入

実行したら、その結果の行を追加してPRを送ってください。モデルの評価を下げる数値も、上げる数値と同じように役立ちます。この表の目的は、宣伝ではなく、どのワーカーが実際に動作するのかを示すことです。

想定しておくべき点が1つあります。 DeepSeekの応答は9件中1件もMarkdownのフェンスで囲まれていませんでした。小規模なモデルではほとんどの応答がフェンスで囲まれますが、これは能力ではなく解析の問題です。Bifrostはすでにフェンスを除去します。モデル自体には問題がないのにフェンスが原因で失敗する場合は、モデルの評価を下げる要因としてではなく、バグとしてここに報告してください。

---

マシンの外に送られるもの

ワーカーに送られる作業単位は、解析済みのブロック1つ、つまり1つのメソッドであり、元のファイルが送られることはありません。これは後から追加された機能ではなく、設計上の帰結です。置き換え後のコードがオーケストレーターのコンテキストを経由しなければ、それ以外のどこにも送られません。

これが意味しないこと。 ブロックは、設定したエンドポイントに平文で送られます。内部アーキテクチャを記述している可能性のある指示も同様です。

すでに講じられている保護策。 Heimdall が実行されるのは、書き込みの前ではなく、送信の前です。シークレットが自己完結したトークンの場合はプレースホルダーに置き換えられ、ワーカーがその周囲のコードを変換し、ファイルを書き込む前に元の値に戻します。すべてのプレースホルダーが正確に1回ずつ戻らなければ、何も書き込まれません。安全にマスキングできないものがあれば、送信自体を中止します。実際のコードベースで測定した誤検出率は、1,291個のシンボルに対して2件で、どちらもキーを保持するのではなく操作するコードを正しく拒否したものでした。この件数は0.1.0のもので、その時点ではシンボルマップがメソッドと関数のみを対象としていました。0.1.4でクラスも指定可能になったため、今日再実行すれば分母はさらに大きくなります。

何も外部に送信してはならないという制約があるなら、答えはペイロードの縮小ではなく、ローカルワーカーです。

設計済み、未実装

残されたギャップの大部分を埋める追加機能が2つあります。どちらもまだ存在しません。設計こそが興味深い点なので、課題の中に隠さず、ここに記載します。

• 送信ログ。 ログには送信内容のバイト数ではなく、サイズが記録されます。送信内容を応答とともに記録するのはほぼコストがかからず、「信頼してください」を「監査できます」に変えられます。
• コメントとリテラルのマスキング。 Heimdall はシークレットのような形式のものをマスキングします。パーサーはすでに構文木を生成しているため、コメントと文字列リテラルは、不透明なマーカーに置き換えて返却時に復元できます。これらはリスクの高いペイロードであることが多く、変換には無関係なこともよくあります。

2つ目に対するわかりやすい反論は、ワーカーが名前を見られなければ品質が落ちる可能性があるというものです。これは測定できる問いであって、反論ではありません。calibratge/calibra.py を使い、マスキングありで9ケース、なしで9ケースを試します。どちらの結果になっても公開します。

---

クイックスタート

Python 3.11 以降が必要です。ランタイム依存関係はありません — サーバーは標準ライブラリで動作し、各言語はそれぞれの公式ツール（外部バイナリとしての php、標準ライブラリの ast）で解析されます。

pipx install mcp-bifrost      # or: uv tool install mcp-bifrost

パッチを適用するプロジェクトの .mcp.json に追加します。

{
  "mcpServers": {
    "bifrost": {
      "command": "mcp-bifrost",
      "env": { "BIFROST_DB": ".bifrost/history.db" }
    }
  }
}

クライアントに名前だけ表示されるツールは、作業中に忘れがちです。 ツールスキーマの読み込みを遅延する MCP クライアントでは、何かを要求するまで Bifrost のツールは名前だけで表示されます。同じ機械的な編集を 5 回続けても、それを促すものは何もありません。まさに、ドッグフーディングを始めて最初の 6 か月間に起きたことです。insert_case はセッション全体を通して使われないまま、同じ switch-case パターンが何度も手作業で編集され、さらに 2 つの並行編集間で衝突しました。これは、insert_case のアンカリングが防ぐためにあることそのものです。このプロジェクトでは、このギャップを一度埋めましょう。

mcp-bifrost init-hook            # writes .claude/settings.json in this project
mcp-bifrost init-hook --global   # or: ~/.claude/settings.json, for every project

これにより、Edit／Write 時に、手作業で編集する前に適切な Bifrost ツールがないか確認するようクライアントに促す PreToolUse フックが追加されます。既存のフックはそのまま維持されます。いつでも再実行できます。フックがすでに設定されていれば何も行いません。プロジェクトレベルの .claude/settings.json をコミットすれば、1 台のマシンだけでなく、リポジトリとともにこの通知を共有できます。

ただし、通知だけでは不十分だとわかりました。フックを設定し、50 回以上発動させた本格的なビルドセッションでも、新しいファイルの 96％が生の Write で作成されました（docs/critical-review.md、RF-13 を参照）。その後のセッションで状況がはっきりしました。クライアントに直接尋ねると、ツールを使っていないと認め、ツールを読み込んで 1 回呼び出したものの、その後も新しい switch case を 1 つ、新しい関数を 2 つ、メソッドの書き換えを 2 つ、すべて手作業で編集しました。その間、通知は毎回発動していました。すでに読んで同意した文章では、次の判断は変わりません。

そこでフックは、次の 2 つのケースをブロックします。

• このサーバーが対応する既存ファイル（.php、.py）への Edit または Write。プロジェクトの .mcp.json で bifrost が登録されている場合が対象です。拒否時には、パターンごとに適切なツール名（insert_case、insert_symbol、fix_symbol、fix_symbols、fix_range、patch_group）を提示します。
• まだ存在しないファイルを作成する Write。同じ拡張子のファイルがすでに 3 つ以上あるディレクトリが対象です。推奨する create_file(model_from=<nearest sibling>) を提示します。

それ以外はすべて通知にとどまります。最初のゲートはスコープをディスクから読み取るため、--global でも安全です。このサーバーを設定していないプロジェクト内の .php や .py ファイルがブロックされることはありません。編集対象となるシンボルが本当に存在しない場合は、touch .bifrost/hook-override を実行すれば次の編集を許可できます。これは使用時に消費されるため、セッション全体で通知を無効にするのではなく、1 回の編集だけを許可します。

このサーバーを開発する場合は、main のワークツリーからフックをインストールしてください

このフックは強制適用されるグローバルなもので、開発用チェックアウトから編集可能な状態でインストールすると、そのチェックアウトが現在いるブランチの内容を実行します。フィーチャーブランチに切り替えると、マシン上のほかのすべてのプロジェクトに適用されるゲートが気付かないうちに変わります。これは、まさにこのツールが取り除こうとしている類の予期せぬ動作です。main に固定した2つ目のワークツリーを用意し、そちらをインストール元に指定してください。

git worktree add ../MCP-Bifrost-main main
pipx install --force --editable ../MCP-Bifrost-main

開発は元のチェックアウトで、どのブランチでも続けられます。稼働中のフックには影響しません。main にマージした後、意図的にワークツリーを更新してください。

git -C ../MCP-Bifrost-main pull       # editable install: no reinstall needed

パスを指定してサーバーを起動する .mcp.json にも同じことが当てはまります。PYTHONPATH は開発に使うチェックアウトではなく、main のワークツリーを指すようにしてください。

または、インストールせずにソースから実行します。

git clone https://github.com/FixemBCN/MCP-Bifrost.git
cd MCP-Bifrost
python3 -m unittest discover tests    # 308 tests, ~32s
python3 -m mcp_bifrost.server         # same server, PYTHONPATH=.

PATH に php がない場合は、OK (skipped=80) と表示されます。 これは想定どおりです。この80件のテストでは実際の PHP トークナイザーを動かすため、PHP のないマシンでは検証できることがありません。残りの228件（ゲート、パッチャー、予算、Heimdall、Python アダプター）は標準ライブラリだけで実行できます。自分のマシンで PHP 関連のテストも検証したい場合は、php-cli をインストールしてください。CI では、プッシュのたびに両方の環境でテストを実行します。同様に、git が必要なテストは91件です。

キーはそのファイルに記述しないでください。 プロジェクトのルートにある .bifrost.env に記述してください。環境変数にキーがない場合、サーバーはそこから読み込みます。

echo "DEEPSEEK_API_KEY=sk-..." > .bifrost.env
chmod 600 .bifrost.env
echo ".bifrost.env" >> .gitignore

または、キーを使わずに BIFROST_WORKER_BASE_URL をローカルモデルに向けることもできます。詳しい手順と、重要なものに接続する前にすべきことは、マニュアルをご覧ください。

ツール

ツール	機能
fix_symbols	1つの指示を複数のシンボルに適用します — メインのツールです
fix_symbol / fix_range	1つのシンボル、または明示的に指定した行範囲を書き換えます — 任意の verify コマンドを実行でき、失敗時には変更を元に戻します
insert_symbol / insert_case	関数、メソッド、クラス、または switch ルーターへの分岐を追加します
create_file	新しいファイルを書き込みます。既存ファイルを参考にすることもできます — 任意の verify コマンドを実行でき、失敗時にはファイルを削除します
patch_group	複数の操作を1つのトランザクションとして実行します
export_docs / publish_session	ログから変更履歴を作成します。確認可能なブランチにまとめて反映します
revert_patch / revert_session	1つのパッチ、またはバッチ全体を取り消します

---

キャリブレーション

サーバーのコードを書き始める前に、1つの問いに答える必要がありました。

実際のコードベースにある実際のメソッドをコンパクトなスキーマに詰めたとき、 ワーカーは、何も壊さずに適用できるコードを返すでしょうか？

calibratge/ のハーネスで検証します。依存関係はなく、Python の標準ライブラリと php バイナリだけを使います。

export BIFROST_TARGET=/path/to/your/codebase
python3 calibratge/calibra.py --dry-run    # show cases, no API calls
export DEEPSEEK_API_KEY=...
python3 calibratge/calibra.py --cases 9

結果：前提は成り立ちます。 有効な JSON は9/9件、同一性タスクでバイト単位の一致は3/3件、元の行が失われなかったものは3/3件、Markdown のフェンスで囲まれたものは0/9件、平均レイテンシーは2.6秒です。

また、ワーカーとは無関係で、本番環境のファイルを気付かないうちに破損させるバイトオフセットのバグも検出しました。詳細な報告はdocs/calibration.mdをご覧ください。

リポジトリの構成

パス	内容
mcp_bifrost/	サーバー
CHANGELOG.md	各バージョンで変更された内容と、それ以前に問題があった理由
docs/	マニュアル、アーキテクチャ、批判的レビュー、キャリブレーション、比較、ライセンス
tests/	308 件のテスト — 80 件は php が必要で、91 件は git が必要です。存在しない場合はスキップされます
brainstorm/	作業記録 — 選択を覆したものも含め、各決定に至った経緯
calibratge/	測定用ハーネス
.github/	バッジに表示されるワークフロー。php を使ったテストスイートと、php なしでの再実行

---

コードの背景

完全に透明性を保つためにお伝えすると、このコードベースには、手作業で書かれた行が一行もありません。 人間が指揮する AI のプロセスを通じて、構想、検討、実装、テスト、文書化が行われました。実際にどのようなプロセスだったのか、できる限り正確に説明します。

人間 — 問題、決定、方向性。 私が最初の仕様を提示し、どのワーカーモデルを使うか、どの言語に対応するか、何を削るか、次に何を作るか、ライセンス、命名、いつ作業を止めるかといった、すべてのプロダクト上の決定を下しました。以前の決定を覆したことも何度かあります。ライセンスは当初、再販禁止のソース公開ライセンスでしたが、コントロールより普及のほうが重要だと判断したため、最終的に Apache-2.0 になりました。また、システムが何をしてはならないかも決めました。結果として、こちらのほうがより重大な決定でした。

Claude Opus — 敵対的な設計レビュー。 実装前に、Claude は外部の立場から失敗する理由を探すために仕様をレビューし、12 件の指摘をまとめました。そのうち 2 件は、私が承認していた設計要素を取り除くことにつながりました。仕様が頼りにしていた中心的な「perimeter check」は、失敗する可能性がないことが判明しました。また、プロジェクトが掲げていた正当化の理由であるトークン削減は、単一の編集ではわずかな効果しかなく、大量処理の場合にのみ決定的な効果があることが示されました。どちらも brainstorm/ に、編集せずそのまま保存されています。

コードより先に測定。 設計をそのまま信頼するのではなく、まずキャリブレーション用ハーネスを作り、実際のコードを使って実際のワーカーで実行しました。9 件中 6 件で失敗しましたが、いずれもワーカーの問題ではありませんでした。原因はバイトオフセットのバグで、アクセント付き文字を含むファイルを、気づかれないまま破損させるものでした。また、Claude のレビューで挙がった指摘のうち 2 件が誤りであることも判明しました。これらの修正は、元の主張を置き換えるのではなく、その上に追加されています。

Claude Opus — 中核部分、委任モデル — 周辺部分。 Claude は、パース、パッチ適用、検証ゲート、シークレット処理、エンジンを直接記述しました。周辺モジュール 2 つと、元のテストスイート全体は、小型モデル（Haiku と Sonnet）にサブエージェントとして委任しました。その後、テストスイートはおよそ 2 倍になりました。0.1.2〜0.1.5 で追加されたテストは Opus が記述し、Bifrost 自体を使って適用したもので、元の 128 件のテストでは MCP サーバー、ワーカーの HTTP クライアント、VCS レイヤー、Python アダプターのいずれも実行されていなかったために追加されました。この分担は、コスト削減ではなく意図的なものでした。パッチ適用コードに初めて取り組むモデルは、バイトオフセットのバグを再び持ち込む可能性が非常に高かったでしょう。自然なコードの書き方が、誤った書き方だからです。

委任されたモデルは、Claude が書いたコードに実際のバグを 4 件見つけました。 そのうち 1 件は、ドキュメントブロックを説明対象のメソッドから切り離すもので、もう 1 件は、ネストされた switch 文が分岐を気づかれないまま落とすものでした。どちらもすべての検証ゲートを通過していました。コードに利害関係のないモデルによる敵対的レビューだけが、これらを見つけました。

人間 — レビューと採用判断。 私は作業の順序を指示し、結果を確認し、主張に異議を唱え、何を残すかを決めました。Claude が検証とキャリブレーションを実行し、私はその結果を読み、何を意味するのか判断しました。

このプロセスで提供できなかったこと

このリポジトリの約10,700行を、つまりサーバーの約4,600行、テストの約5,400行、測定ハーネスの約700行を、行ごとにすべて読んだ人間はいません。ここでの信頼性は、意図的に壊したコードを使って確認したテスト、実際のコードベースを対象にした測定、そして検証できないものは一切書き込まない設計に基づいています。手作業による監査に基づくものではありません。

ソースファイルを編集するツールに対して、こうした信頼性では不十分だと考えるのはもっともです。責任に関するセクションでは、ゲートで検出できることとできないことを具体的に説明しています。

README にこれを記載する理由

Bifrost は、その前提を自ら実証するものです。人間が貢献した価値は、コードを入力したことではありません。問題を定義し、コンテキストを管理し、出力に異議を唱え、生成されたコードを信頼できるものにするために十分な検証を求めたことです。

このリポジトリでは、推論、却下した案、敵対的レビュー、測定結果を意図的に残しています。AI が間違え、それを認めた箇所も含まれています。

この記録は最初のリリースで終わっていますが、取り組みは続いています。 その後の経緯は CHANGELOG.mdに記録されています。そこには、発見された不具合と、それまで気づかれずに何を引き起こしていたかが記されています。それ以前にどのように設計に至ったかは、brainstorm/とdocs/critical-review.mdに記載されています。

---

ドキュメント

ドキュメント	内容
マニュアル	どのようなものか、何ができるか、インストール方法、そして利用者が負う責任
アーキテクチャ	何を構築するのか、そしてその理由
批判的レビュー	この仕組みが失敗する理由を探す、新たな視点による検証。12件の指摘があり、そのうち2件は後の測定で反証されました
キャリブレーション結果	ワーカーに依頼したとき、実際に何が行われたか
比較	Aider、Serena、fast-apply と比べた場合の位置づけと、それらが優れている点
ライセンス	利用しているものと、提供するもの

brainstorm/には、作業の記録がまとめられています。最初の仕様、5回の改訂にわたる設計日誌、敵対的レビュー、キャリブレーション結果が含まれています。両者の内容が異なる場合は、docs/を正式な参照先とします。

---

責任

このツールは言語モデルを使って、ソースファイルを自動的に編集します。Apache 2.0 に基づき、無保証で現状有姿のまま提供されます。コードに対してこのツールが行うことについては、利用者が責任を負います。差分を確認し、テストを実行し、意図を持ってデプロイしてください。マニュアルでは、ゲートで検出できることとできないことを具体的に説明しています。

コントリビューション

このプロジェクトへのあらゆる貢献を歓迎します。ここに何か間違いがあるという指摘も含みます。このプロジェクトではすでに、同語反復的だった検証ゲートを1つ削除し、測定によって自らの主張を2つ反証しています。

慣例は1つだけです。そして、それが最も重要です。すべてのテストは失敗しうるものでなければなりません。 詳細はマニュアルをご覧ください。

ライセンス

Apache License 2.0。

Model Context Protocol を基盤としており、Anthropic, PBC により MIT ライセンスで提供されています。MCP-Bifrost は独立したプロジェクトであり、Anthropic, PBC との提携、承認、支援を受けていません。