MCP Bifrost

What mcp-bifrost MCP server does

The mcp-bifrost MCP server handles mechanically repetitive edits after an orchestrating model has identified the files, symbols, and instructions. It supports PHP and Python, extracts target blocks with language parsers, sends one isolated block and one instruction to a worker, then applies the returned code only after validation.

The worker does not choose files, plan the change, or inspect the wider codebase. The server is the component that writes files, and it keeps patch history outside the orchestrator's context. Git object storage is used to preserve prior content for later reversal.

How it works

A typical flow is:

1. An orchestrator identifies the symbols and divides the work.
2. Bifrost extracts each target block from the source file.
3. A worker model rewrites the isolated block.
4. The server checks the result and rebuilds the file with an atomic splice.
5. The applied patch is logged for review or rollback.

By default, validation checks that the source offsets match what was sent, the rebuilt PHP or Python file passes syntax validation, and the returned block defines exactly one symbol. An optional substance gate checks for disappearance of calls, variables, or control keywords. The server does not determine whether a change is semantically correct.

Setup and configuration

The project targets Python 3.11 or newer and accepts an OpenAI-compatible chat-completion endpoint as its worker. The README shows configuration with environment variables such as:

• BIFROST_TARGET: path to the codebase being edited.
• BIFROST_WORKER_BASE_URL: worker endpoint, for example a local OpenAI-compatible service.
• BIFROST_WORKER_MODEL: model identifier used for rewriting.

The documented examples include Ollama, llama.cpp's server, LM Studio, and vLLM as possible endpoint types. No key is needed when using a non-default endpoint. A calibration script can measure a chosen worker's output format, identity preservation, line retention, fencing, and latency before bulk work.

Tools and capabilities

The mcp-bifrost MCP server exposes these MCP tools:

• fix_symbols: applies one instruction across multiple symbols and is intended for bulk transformations.
• fix_symbol: rewrites one symbol or an explicit line range, with an optional verification command; failed verification reverts the change.
• insert_symbol: adds a function, method, class, or switch-router branch.
• create_file: creates a file directly or by analogy with an existing file; optional verification removes it when verification fails.
• patch_group: combines several operations into one transaction.
• export_docs: creates a changelog from the patch log and batches changes onto a reviewable branch.
• revert_patch: reverses one patch or an entire batch.

These operations provide atomicity and rollback, but they do not make dependent edits sequential. A grouped patch is therefore not a substitute for planning changes whose later shape depends on an earlier result.

Limitations and notes

Reach for mcp-bifrost MCP server when the work is already analyzed and repeated across many symbols. It is not designed to investigate an unknown failure, and the documented latency is about 2.6 seconds per block in measurements against DeepSeek. The token benefit is strongest for large batches; a single small edit may not justify the extra path.

Only PHP and Python are supported. Adding another language requires a parser adapter. Validation checks structure and syntax, not program meaning, so a syntactically valid but semantically incorrect patch can still pass. Cross-file work that depends on edit ordering also falls outside the guarantees described for patch_group.