MCP-Bifrost

200個のメソッドを安価なモデルで書き換え、結果の1行も高価なモデルのコンテキストを通すことなく、コンパイルが通らないものをディスクに書込むこともない。

オーケストレーターモデルが分析・分割したコード作業を受け取り、言語自身のパーサーで正確に対象ブロックを抽出し、書き換えをより安価なワーカーモデルに委任し、結果を検証し、原子的に適用し、その全体をオーケストレーターのコンテキストの外に記録するMCPサーバーです。

頭脳が決定する。筋肉はタイプする。Bifrostは、その間の神経——そして、壊れたものは何もディスクに届かないことを保証する部分——です。

以下の例で頭脳はClaude、筋肉はDeepSeekですが、DeepSeekはただ手元にあったというだけのモデルです。どちらも必須ではありません。手元のマシン上の7Bモデルがより興味深い選択肢である理由は、ワーカーで説明します。

なぜ

大規模なコードベースをLLMで編集するとき、本当のボトルネックはひとつだけです。それは知性ではありません——コンテキストです。4,600行のファイルのうち30行を変更するために全部を読むと、オーケストレーターのウィンドウが、二度と使われないテキストで燃やされます。

Bifrostの前提は単純です。コーディングの機械的な半分——置換テキストを書く部分——は高価なモデルを必要とせず、そのコンテキストを通る必要も一切ないということです。

正直な見方は（RF-4を参照）：単一の小さな編集なら節約は確かだがささやかです。というのも、オーケストレーターは通常、何をやりたいかを伝えるために、やはりコードを読まなければならないからです。桁違いの効果は量にあります——指示を書くために何も読む必要がない、多数のsymbolにまわる変換のことです。

それが本来のユースケースです。「このバグを直す」ではありません。

Related MCP server: ropey

使わない場面

• 調査的な作業。 「クラッシュの原因を見つけて」というのは、Bifrostが実行できる指示ではない。始める前に、対象のsymbolが分かっている必要があります。

• 単発の小さな編集。 トークンの節約はごくわずかです。それは私たちも認めています（RF-4参照）。エージェントの普通の編集ツールを使ってください。

• レイテンシの敏感なループ。 ブロックあたり約2.6秒（DeepSeekで測定）。

• 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

オーケストレーターが何をどう行うかを決めます。ワーカーは何も決めません。ディスクに触れることを許可されているのはサーバーだけであり、すべてのゲートを通るまで拒否します。

検証ゲート

3つがデフォルトでオンであり、4つではありません。 実質ゲートは粗い正規表現チェックで、キャリブレーション中には一度も発火しませんでした。良いパッチを拒絶するゲートは、配備を待つゲートより悪いことはありません。

対象範囲外のバイトを比較する「perimeter check」は、設計され、実装され、そして削除されました。サーバーはファイルを original[:start] + block + original[end:] として再構築するため、範囲外は構造的に保たれ、その検査が失敗することは構造上ありません。キャリブレーションがそれを確認しました——ゲートは9/9を報告しましたが、3つのファイルは文法的に壊れたままでした。RF-1参照。

ロールバック

Gitはすでにコンテンツアドレス型データベースなので、そう使います。各パッチの前にgit hash-object -wと実行すると、ログに入るblob SHAが得られます。戻すのはgit cat-file blobです。重複排除と圧縮は無料で、汚れた作業ツリーでも動作し、独自のスナップショット形式を保守なくて済みます。

ワーカー

DeepSeekは「たまたま手元にあった」モデルであり、このリポジトリの数値はすべてそれを基準に測定されています。要件ではありませんし、おそらく「もっと面白い動かし方」でもありません。

ワーカーの仕事は意図的に狭いです。分離された1ブロックと1つの指示を受け取り、1ブロックを返すのみ。ファイルを選びません。変更を計画しません。何を編集するかも決めません。コードベースのそれ以外のものを見ません。それは果敢な7Bコーディングモデルでもできる仕事です。そして、弱いワーカーのミスをディスクに達する前——ではなく後——に捕えるためにこそ定期間がします。

だからこそ、ローカル環境のほうが説得力あります:

• コードがマシンの外に出ない。 プロプライエタリなコードベースでは、これは好みのことではなく条件です。

• コストがゼロになるのは、まさにこのツールのためにある仕事量——1回の実行で数百ブロックは特別ではなく日常——においてです。

• コンテキスト要件はごく小さい。 ファイルではなく1つのメソッド。8kウィンドウで十分です。全体の設計は、ワーカーが見るのは必要な分だけにする。

• 弱いワーカーで十分に役立つのは、 すべての出力が「何かのためになる」前に、パース・構文チェック・diffを受けるから。悪いブロックはファイルの破壊ではなく、リトライ1回のコストです。

最後の部分が本当の論点です。コード生成を小さなローカルモデルに任せて通常良く考えられないのは、出力を信頼できず、手作業で検査するコストが書くコストを上回るからです。Bifrostの答えは、チェックは機械的なので、機械に任せればいいとということです。

OpenAI互換のエンドポイントならどれでも動きます——Ollama、llama.cppのサーバー、LM Studio、vLLM:

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

デフォルト以外のエンドポイントなら、APIキーは不要です。

ワーカー互換性

ローカルモデルはまだ1本体されていません。 エンドポイントは設定可能であり、プロトコルはただの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

もし実行したら、その行を載せてPRを開いてください。モデルを悪く見せる数値は、良く見せる数値と同じだけの価値があります——このテーブルは、これが実際に動くワーカーを伝えるためのもので、広告のためではありません。

一つだけ予想しておくこと。 DeepSeekは、9件中0件しかマークダウンフェンスで包んで返しませんでした。小さなモデルはだいたい全部をフェンスします。それは能力の問題ではなくパースの問題です。Bifrostはすでにフェンスを除去します。モデルがそれ以外は問題ないのにフェンスで失敗する場合は、モデルのせいにするをやめて、ここにバグとして報告してください。

外に出るもの

ワーカーに送る作業の単位は、パースされた1ブロック——単一のメソッド——であり、源泉ファイルは決して送りません。これは「設計の帰結」であって「付けた機能」ではありません。置換コードがオーケストレーターのコンテキストに通らないなら、他の他のどこも通らないということです。

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

すでに守られていること。 Heimdallはsendの前ではなく、書込む前に実行される。秘密が自己完結型トークンである場合、プレースホルダーに置き換えられ、ワーカーはその回りのコードを変換し、元の値はファイルが書かれる前に戻します。すべてのプレースホルダーは一度だけ戻す必要がある。さもないと何も書き込まれません。安全に隠せないものは、送信そのものがブロックされます。実性能の偽陽性率は：1,291 symbols 中2件、どちらもキーを「保持」ではなく「操作」するコードを正しく拒否しています。

「外に出しては完全にいけない」という制約があるなら、その答えは小さなペイロードではなく、ローカルワーカーです。

設計されたが、作られていない

残る間隙のほとんどを埋める追加機能は2つ。これらはまだ存在しません。設計が面白い部分なので、issueに埋めず、ここに名前で挙げています。

• Eグレスログ。 送ったバイトではなく、送った「サイズ」をログに記録すること。送り返ってきたものと一緒に記録するのはほぼ無料で、「私たちを信じてください」を「監査してください」に変えてくれます。

• コメントと文字列リテラルの難読化。 Heimdallは秘密の形をしたものを難読化します。パーサーはすでにツリーを生成しているので、コメントと文字列リテラル——しばしば最も高リスクのペイロードであり、変に無関係で頻度も高い——を、不透明なマーカーに置き換えて、返ってきたら復元できます。

2つ目への率直な反論は、「ワーカーが名前を見れなくなると品質が落ちるだろう」ということです。しかしそれは、主張ではなく測定可能な問題です。難読あり9件、なし9件、calibratg/calibra.py。どちら結果になっても公表します。

クイックスタート

Python 3.11以上です。ラ実行時依存関係なし — サーバーはは標準ライブラリのみで動作し、各言語は公式のツock( phpは外部バイナリ、ast はstdlib) でパースされます。

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

修正したいプロジェクトの .mɔ.json に追加します:

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

では、インストールせずソースから:

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

キーはそのファイルに入れないでください。 プロジェクトのルートにある .button_abuild.env に入れます。サーバーは、環境にないそのプロジェクトのファイルを読みます:

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

それともキーを一切使わず、 BIFGRNRKER_AB_SE_URL をローカルモデルに委すこともできます。完全な手順と、大事に使う前にすべきことは, [the manual](https://github.com/ FixemB CN/MCP-Bイfrost/平面/等docs/manual.mb) にあります。

ツール

キャリブレーション

サーバのコードを1行書く前、一つの問い答えなければなもならなかった:

実際のコードベースから持ってきた実際のメソッドを、コンプクをスキマに込んで、ワーカーは何も壊さずに適用できるコードを返すのか ?

それに答えるのが calibratge/ のハーネスだ。依存関是被ゼロ。 Python 標準ライブRリと 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

結果: 前提は成り立つ。 9/9 が有効な JSON、3/3 が同一性タスクトでバイト状位同値、3/3 が元の列を喪っておらず、 Markdown フェンスで包まれたのは 0/9、平均 2.6 秒のレンシ。

も、それとは無関係に、ブ番環环で静かにファイルを破損するバイトオ фセットのバグを検出できた。詳しは: docs/calibration.md.

リポジジトリ構成

コードの裏側

完全に透明く述べる。 このコドベスのノードは1行も手で書かれていない。 人間が指示するAIプセスによる構想、問、実装、テスト、ドキュメント化がされてで、この "実際どういういうこだったのかを、できる限り正確に述べる。

人間 — 問題、決定、方向付け。 私は最初の仕様み込んで、すべルのプダクト決定を下しした。: どのワーカー・モデルか、どの言語か、何を々スするか、次に何をビルドするか、ラセンス、ネーミング、時期をどの停するか。以前の決定をいくつか覆した — ラセンスは、最初は転売禁のソース公開型だっが、リーチが制御より重要だと断した後、最終的に Apache-2.0 にした。また、シそテムが拒否すべきべく決定も下ししたが、この方が後できわめて重要な半分だっ。

Claude Opus — 対抗的レビュー。 実装前にClaudeは、スペックを失改する原因を探すための第三者の視点でレビューし、12件の所見を出した。そのうちの2つは、私が承認了した装計を失したさせた。: 仕様が頼りとだした「周チェ隆」の中心、" absolute correctness" ことを示 (実際には失敗し得具えないもの) であり、もう 1つは、プロジェクトの表明の根拠 — トーク節約 —が一つの編修では限界的で、到了バッチ編修だけで决的隗であた。それら2つは、編修されずに brainstorm/ に収められている。

測定が先、コードは後。 設計を信頼する代かを行に、はじめにキャリブレーション・ハーネスを、実コードと実ワーカーに対する実測で構築し実行した。9件の中6件失敗した — こその要因はワーカーではない。原因はバイトオフセットのバグで、アクセント文字を含むファイルを静かに壊していただろう。また、それはClaude自身のレビュー所見の2つを誤りと認証した。それはら正さは、元の成張をこれ置るえ剣にするのではなく、その上のに重ねる。

Claude Opus — 中心部; 委譲されたモデル — 周辺部。 Claude はパース、パッチ、検証、ゲート、シークレット、处理、エンジンを 직접書いた。2つの周辺モジュールとテストスイート全体を、サブエージェントとして遂行される小なめのモデル (Haiku と Sonnet) に委譲した。この分割はコスト節約それも理由ではなく、故意的だった: パッチング・コードに「冷えた状態」すなわち何の前提もなく取りかかるモデルは、バイトオフセットのバグを再導する可能性が非常高くなる。何故、そのコードを自然に書く方法が、実る誤っている書く方法であるからだ。

※ 委譲されたモデルすは実バグを4件のバグを発見**した。それはCLというが書いたコードに含まれ、一つは docbl ck をドキ心メントするメソッドから引きはがすもの、もう一つはネストした switch 文言のbranch を黙って落とすものだった。この両方とも、あらゆるバリデーションのゲートをすり抜げた。が出たのは、コードに損得のないモデルによるア ドバーサリー-review just as only one.

A員 — レビューと承認。** 私がその一連安を指示し、結果を検査し、間違いと疑問を指し、何を残すかを決めた。Claude がフェーション・測定を実施し、私が有した返りを書を読み、その意味を判断した。

このプセスが得られなかったもの

人な人間が、. リポジトリの約 7,400 行 — サーバーおよそ4100行、テストおよそ27000? — を、行ごとに読んではいない。ここでの信頼性は、意図的に破壊したコードに対して行ロセス・テスト、実コードベースへのの実測、検証できないものは傷つない設計という基盤にあり、人手での監査によるとしてはない。

そのよこという信頼頼性のうツールは、ソースをードを編修する・ト具としてにあなたー求めたい類型ではないのであば、それ理れだ。それゲートがえて検出するだろうとしないにかいては、コマでは説明していません。

何これ가 README にあるなのか

Bifrost は自分の前提の披露である。価値ある人間の貢献の核心、それはコードをテツピングでではなく、問題を定義し、コンテキストをコントロールり、出力を監査し、生成されたコートに信頼性が持てる十分なバリデーションを要求し続るということでした。

このリポジトリは、自分の思考ログ、退けたアイデノ、対抗的なレビュー、そして測定地を、Aいが自分の「違えた」と負け認めた部分も、故意に収録した。

ドキュメント

brainstorm/している … working record: 初の仕様、五回のデザイン日誌、adversarial review, and the calibration results. docs/ 是 reference, and wins tor the same.

Responsibility

This tool uses source files. # Manual 2.0 — "as is, without liability" you are responsible for what it does to your code. Read the diff, run your tests, and deploy with intent. Manual explains in detail what gates will and will not be catch.

Contribution

All contributions are welcome — including arguments that something is wrong here. This project has already deleted one validation gate as tautological, and rejected two of its own claims by measurement. Let's one convention, and that's the important one: Every test must be capable of failing. details in the manual.

License

Apache License 2.0. It is built on the Model Context Protocol, MIT licensed by Anthropic, PBC. MCP-Bifrost is an independent project, not related, endorsed by, or sponsored by Anthropic, PBC.