MCP-Bifrost
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BIFROST_DB | No | Path to the Bifrost history database file. Defaults to .bifrost/history.db. | .bifrost/history.db |
| DEEPSEEK_API_KEY | No | API key for the worker endpoint. Required when using the default DeepSeek endpoint; can be omitted when a local endpoint is configured via BIFROST_WORKER_BASE_URL. May also be supplied via a .bifrost.env file in the project root. | |
| BIFROST_WORKER_MODEL | No | Model identifier for the worker endpoint (e.g. 'qwen2.5-coder:7b' or 'deepseek-chat'). | deepseek-chat |
| BIFROST_WORKER_BASE_URL | No | Base URL of the worker model's OpenAI-compatible endpoint. If not set, the default worker endpoint (DeepSeek API) is used. When set to a local endpoint, no API key is required. | https://api.deepseek.com/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fix_symbolsA | Apply ONE instruction across MANY symbols. This is the tool this server exists for. For a single target, use fix_symbol instead — the parallel worker calls here only pay off once there is more than one. The order-of-magnitude win is a transformation stated once and applied to symbols you never read: 'add a docblock to every method here', 'switch every call to the new API'. Worker calls run in parallel, writes run in series, and each symbol is re-resolved by name just before its write, so earlier patches moving later offsets is not a problem. |
| fix_symbolA | Rewrite one named function, method or class in place. The symbol is extracted with the language's own parser, sent to a worker model, validated, and spliced back atomically. Addressing by name is immune to line drift, so it is safe to issue many against the same file. Skip this only when the edit is too small for a symbol boundary to matter — a one-line typo, a single config value, a comment. Anything that changes what a function does should go through here even when you already read the code: unlike a manual edit, this re-resolves the symbol by name (immune to line drift from earlier edits landing in the same file), validates syntax before writing, and is rollback-able from a saved git blob. Having read the file first buys a manual edit none of that. |
| fix_rangeA | Rewrite an explicit line range. The escape hatch for code that does not live inside a symbol — module-level configuration, a branch of a switch, markup embedded in the source. Prefer fix_symbol where one applies: line numbers move when earlier patches land, and a stale range is rejected rather than applied. |
| insert_symbolB | Add a new function, method or class next to an existing one. Classes are addressable, so a class is a valid anchor and a valid thing to insert. Anchoring to a symbol rather than a line number is what makes this usable in a batch: the anchor does not move when everything above it changes. The anchor is also shown to the worker as a style reference, so the new code matches its neighbours. |
| insert_caseA | Add a branch to a |
| create_fileB | Write a new source file. Never overwrites. Pass |
| patch_groupA | Apply several operations as one transaction: all of them land, or none do. Use whenever a change spans more than one file — a new class plus the require_once that references it plus the method that returns it. Applying that halfway leaves the project worse than not starting. On failure everything already applied is rolled back in reverse order. |
| export_docsA | Turn the patch log into readable documentation — a changelog, release notes, a summary of a batch. Every patch already recorded why it was made, at no cost to your context; this reads that back. Runs ONLY when asked: nothing generates it automatically. |
| publish_sessionA | Put this session's changes on a branch as one reviewable commit, with a body listing every change and the reason recorded for it. Worth doing after any sizeable batch: a batch loose in the working tree is close to unreviewable, and where there is no test suite, review is the only safety net there is. Opening a pull request is opt-in and pushes to the remote — ask before setting it. |
| revert_patchB | Undo one patch by id, restoring the file from the blob saved in git's object store before it was applied. |
| revert_sessionA | Undo every patch applied in this session, newest first. Use when a batch has gone wrong partway: you rarely want to undo one patch out of twenty, you want to undo the batch. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Tools are sharply delineated by scope: fix_symbols for batch symbol edits, fix_symbol for single symbols, fix_range for line ranges, insert_symbol/insert_case for insertions, create_file for new files. The descriptions explicitly guide when to use each, preventing misselection between overlapping editing operations.
All 11 tool names use lowercase snake_case with a consistent verb_noun or verb_object pattern (fix_symbols, insert_symbol, create_file, patch_group, revert_patch). No deviations or mixed conventions.
11 tools is well-scoped for a code transformation server. Each tool fills a distinct niche: single/multi/range edits, insertions, file creation, transactions, documentation, publishing, and reverts.
Core lifecycle is covered: create, modify, insert, batch transaction, revert, and publish. Minor gaps exist, such as no explicit delete/remove operation and no read/get tool, but agents can work around these using fix_range or fix_symbol.