Agenten stärken
Installation vom Herausgeber. Kein PlugMCP-Endpunkt.
Host a copy with our keys and logs.
Noch kein paketiertes Release in der Registry. Folgen Sie der README des Repositorys.
Remote-URL oder ein Befehl auf Ihrem Rechner? Worin sich die beiden Installationen unterscheiden
Auf PlugMCP ausführen
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
StartenVom Herausgeber
Claude Code plugin for any Bifrost MCP gateway: plugin registration with lifecycle hooks, skill discovery, agent-driven memory, and MCP.
Primary Target: Claude Code Plugin Registration (includes hooks, skills, and memory). Standalone Remote MCP support is also available for Claude Desktop & web custom connectors.
Claude Code + Claude Desktop plugin for any Bifrost MCP gateway: one-command setup, skill discovery, agent-driven memory, signed admin policy, and OAuth 2.1 for Desktop.
The skill-discovery and memory features need a gateway that exposes a skill server and/or a memory server. Without them, the plugin still wires up the gateway and degrades gracefully — those features simply no-op.
Five hook events are registered in hooks/hooks.json, run by
four scripts — PostToolUse and PostToolUseFailure share one. All of them fail
silently and always exit 0, so a broken gateway can never block a session.
Cached context is emitted for up to 14 days and labelled with its age once past 24 hours, rather than withheld — the session that has been away longest is the one that needs the primer most. A background refresh runs at most hourly.
See guidance/bifrost-guide.md for the full engineer guide.
Claude Desktop is one app with three tabs (Code, Cowork, Chat), and each tab hosts plugins differently. Counting the CLI and claude.ai on the web, that is five surfaces the plugin can run on:
"Hooks and sub-agents run only in Cowork, so they appear grayed out in chat." Source: Use plugins in Claude
On the Chat tab and on claude.ai web, this plugin's memory auto-injection, skill-discovery hints, and usage tracking do not run, because all three are hook-driven. What still works there: the four bundled skills, the five slash commands, and the gateway's MCP tools.
/plugin marketplace add neXenio/bifrost-plugin → /plugin install bifrost-plugin+ button next to the prompt box → Plugins → Add plugin~/.claude.Every path prompts for the plugin's config at install time: the gateway URL
(gateway_url, prefilled with https://bifrost.culture4.life/mcp) and a
virtual key (virtual_key).
Get the key yourself, no ticket needed. Open
https://bifrost.culture4.life/, sign in
with your company account, and the page shows your key with a copy button.
The first visit creates it, later visits show the same one, and there is a
Rotate button if it ever leaks. Your sign-in address has to be on
luca-app.de or nexenio.com, otherwise the page answers 403 domain not permitted after an otherwise successful login.
That is the whole install for someone who does not use a terminal: get the
key, add the plugin, paste the key. The opt-in auto_login option removes the
paste step by fetching the key through company sign-in.
The virtual key (vk_..., self-served from
https://bifrost.culture4.life/) is the auth
path that works today, on every surface, with nothing set in your shell.
Paste it into the virtual_key field at install time and the MCP connection
is live.
With auto_login on and virtual_key blank, the first interactive session
opens the company sign-in page once and caches the key it gets back in
~/.cache/bifrost-plugin/vk. The plugin no longer ships an oauth block in
.mcp.json (removed in 1.9.0): Claude Code never substituted
${user_config.oauth_client_id} inside it, so Keycloak always received the
literal placeholder, and it offered a second, broken sign-in path next to the
working one. A wrong key returns a 401 with no WWW-Authenticate header;
clear the virtual_key field rather than leaving a bad one in it.
Prefer the plugin install path above. Use this only where you cannot install
the plugin at all (~/Library/Application Support/Claude/claude_desktop_config.json
on macOS):
{
"mcpServers": {
"bifrost": {
"command": "npx",
"args": [
"mcp-remote", "https://bifrost.culture4.life/mcp",
"--transport", "http-only",
"--header", "x-bf-vk:${BIFROST_VK}"
],
"env": { "BIFROST_VK": "vk_<your-key>" }
}
}
}
No spaces around : in the --header arg (argument-parsing quirk on some
platforms). This file then contains your key, so treat it as a secret and
keep its permissions tight.
The gateway URL and key come from the install-time plugin config
(gateway_url / virtual_key), and the hooks read those same values, so a
normal install needs nothing here. The env vars below are overrides, plus the
knobs that have no plugin-config equivalent (see
Persisting env vars).
Credentials resolve in this order: the BIFROST_URL + BIFROST_VK pair, then
the plugin config, then a scan of ~/.claude.json. Each source is
all-or-nothing, so a URL is never paired with a key from somewhere else.
Hooks auto-discover the real skill-server name from your gateway's tool list
(e.g. skills-skill_search → server skills). Check /mcp for the
prefix on *-skill_search / *-get_skill and set BIFROST_SKILLS_SERVER to
match if your gateway does not use the default skills.
By default Claude Code asks for permission the first time it calls each gateway
tool. A gateway exposes a lot of them, so that is a lot of prompts. To approve
the whole server once, add this to ~/.claude/settings.json (all your projects)
or to .claude/settings.json in one repo:
{
"permissions": {
"allow": [
"mcp__plugin_bifrost-plugin_bifrost",
"mcp__bifrost"
]
}
}
A bare mcp__<server> rule covers every tool on that server; mcp__<server>__<tool>
narrows it to one. Both names are listed above because the server is called
bifrost when its .mcp.json is picked up as a project MCP server and
plugin_bifrost-plugin_bifrost when it arrives through the plugin — run /mcp
to see which one you have. Extra rules for a server you do not have are inert.
Two caveats worth knowing before you rely on this:
agent and subagentStatusLine settings; a permissions block in
plugin.json passes claude plugin validate and is then silently dropped at
load time, so it looks applied and is not. Granting tool permission stays a
decision on your side of the boundary, which is the right default — it just
means this snippet is a manual step.settings.json. On those surfaces,
approve the server when prompted.For a fleet, the same block goes in the managed settings file your MDM deploys, which also stops individual users from removing it.
The plugin works against any Bifrost gateway — point BIFROST_URL at it. The only
deployment-specific behaviour is the endpoint-migration notice, which tells users on a
retired hostname where to move. It ships configured for the neXenio gateway and is
retargetable:
The retired hostnames are not compiled in: they are per-machine tunnel endpoints,
and a plugin anyone can install should not ship a roster of one organisation's
infrastructure. Enabling the notice therefore takes one line of operator config — put
it where your team already sets env, e.g. ~/.claude/settings.json:
{ "env": { "BIFROST_LEGACY_HOSTS": "old-tunnel-a.example,old-tunnel-b.example" } }
Anyone still pointing at one of those hosts is then told, once per session, to move to
BIFROST_CANONICAL_URL. Without it the notice never fires and users on a retired
endpoint get no signal — which is the trade: nothing published, nothing automatic.
| BIFROST_KEYAPP_URL | SSO keyapp URL — powers the explicit /bifrost-setup browser provisioning flow and signed plugin-config delivery | keyapp_url option, else the gateway's origin |
| BIFROST_PLUGIN_CONFIG | Set to 0 to disable signed plugin-config delivery entirely (kill switch) | (enabled whenever a key is configured) |
| BIFROST_PROMPT_SKILLS | 0 turns off the per-prompt skill search (keyapp prompt-submit.skillSearch) | 1 |
| BIFROST_PROMPT_MEMORY | 0 turns off the per-prompt memory recall (keyapp prompt-submit.memoryRecall) | 1 |
| BIFROST_PROMPT_MEMORY_MIN | Minimum similarity for a recalled fact (keyapp prompt-submit.memoryMinSimilarity) | 0.55 |
| BIFROST_PROMPT_BUDGET_MS | Deadline for both per-prompt searches together (keyapp prompt-submit.budgetMs) | 1500 |
| BIFROST_ROUTE_HINT | 0 turns off the hint to use a gateway server instead of a direct API call (keyapp route-hint.enabled) | 1 |
| BIFROST_REFLECT_MEMORY_STORE | 1 lets the end-of-session check-in store verified facts with memory_store (keyapp session-reflect.memoryStore) | 0 |
| BIFROST_PLUGIN_CONFIG_TTL_MS | How long a fetched plugin-config stays fresh before the manifest is re-checked | 900000 (15 min) |
Whenever a key is configured (env, plugin option or auto-login), the plugin fetches an
Ed25519-signed, content-addressed config bundle from keyapp
(hooks/lib/plugin-config.cjs). The bundle carries the administrator's hook
config plus a tri-state (always_on / available / off) policy for skills and
MCP tools, already merged with your own non-locked opt-ins on the server.
sha256 does not match the
signed manifest, or a gateway demanding a newer plugin means nothing from the
server is applied — the last verified config (or none) stays in effect.signingKeyId changes; a silent key swap is refused and reported.Fact priming is opt-in (BIFROST_MEMORY_PRIME=1); the sizing below only applies when it
is on. Injected memory/KB sizing is adaptive, not a flat fact count — hooks/refresh.cjs
fetches a wider candidate pool from memory_search, then keeps the most similar
results within a character budget (higher-similarity facts get a larger snippet):
If memory_search returns similarity/score metadata, results are ranked and
budget-filled. Rows with no numeric score (an unrecognised response shape, plain
strings, the regex fallback) are dropped while any floor is active; they are kept
only when both BIFROST_MEMORY_MIN_SIM=0 and BIFROST_MEMORY_RELATIVE_FLOOR=0.
There is no separate KB MCP server — KB recall is memory_search against
the memory server, scoped to the KB wing via wing=<BIFROST_KB_WING>. No wing
name is assumed by default, so KB recall stays off until you set
BIFROST_KB_WING to match your gateway's knowledgebase scope.
Get your gateway /mcp URL and personal virtual key (vk_…) from your gateway
operator, then:
/plugin marketplace add neXenio/bifrost-plugin
/plugin install bifrost-plugin@bifrost-marketplace
/plugin enable bifrost-plugin
To pick up a new plugin release:
/plugin marketplace update bifrost-marketplace
/plugin install bifrost-plugin@bifrost-marketplace
Claude Code does not read ~/.zshrc when launched from the Dock or Spotlight.
Use ~/.claude/settings.json so vars apply on every launch:
{
"env": {
"BIFROST_URL": "https://<your-gateway-host>/mcp",
"BIFROST_VK": "vk_<your-key>",
"BIFROST_SKILLS_SERVER": "skills"
}
}
Also add the same exports to ~/.zshrc (or ~/.bashrc) if you use the gateway
from a terminal. Restart Claude Code after editing settings.
Example shell profile lines:
echo 'export BIFROST_URL=https://<your-gateway-host>/mcp' >> ~/.zshrc
echo 'export BIFROST_VK=vk_<your-key>' >> ~/.zshrc
echo 'export BIFROST_SKILLS_SERVER=skills' >> ~/.zshrc # if not "skills"
source ~/.zshrc
The plugin ships a .mcp.json, so the bifrost MCP server wires itself from
the gateway URL and virtual key you enter in the install-time plugin config
prompt, no installer script and no shell env vars needed. It ships
enabled (defaultEnabled: true), so installing it activates it right
away. Leave the virtual key blank at the install prompt and it stays inert —
no key means no gateway connection. /plugin disable bifrost-plugin turns it
off. Type "set up bifrost" or /bifrost-onboard for a guided walkthrough,
/bifrost-debug if something's off.
These are two different skill paths — do not confuse them:
A skill published in the Bifrost dashboard may appear in the repository marketplace
before it is ingested into the MCP skill index. If get_skill says a repository
skill does not exist but the admin UI shows it, the MCP index may be stale — use
the admin Bump all-skills version control or install the skill directly from
the repository marketplace. See Bifrost Skills Repository docs.
If you can't use the marketplace (air-gapped, etc.), clone and run the installer,
a thin wrapper that registers the server through Claude Code's own CLI
(claude mcp add --scope user) — it never edits config files directly:
git clone https://github.com/neXenio/bifrost-plugin
cd bifrost-plugin
export BIFROST_URL=https://<your-gateway-host>/mcp
node scripts/install.js --key vk_<your-key> # then persist env vars as above
node scripts/install.js --dry-run # prints the claude mcp add command instead
macOS: Prefer
~/.claude/settings.json(see above) over shell profile alone. Dock/Spotlight launches do not inherit~/.zshrc.
/mcp endpoint and a virtual key from your gateway operator, entered at the install prompt/bifrost-debug
section 8 covers how to spot it. Skills and the rest of the gateway are unaffected.bifrost-gateway-essentials exists for a specific gap. The SessionStart hook
injects a gateway-specific context block naming your real servers, skill library
and memory corpus, but hooks run only in the Claude Code CLI and in Desktop's Code
and Cowork tabs. On Desktop's Chat tab and on claude.ai web, nothing is injected.
Skill descriptions are loaded on every surface whether or not the skill is
invoked, so that skill's description carries the parts that matter most —
above all that a missing <prefix><server>-<tool> usually means the
capability is in code mode behind executeToolCode, not that it is absent.
That is a partial substitute, not an equal one. A description can state the shape; it cannot name your gateway's actual servers, because those are discovered at runtime. The gateway's own MCP tool descriptions are served by the upstream MCP servers and are not something this plugin can rewrite.
During a session the Stop hook periodically asks whether anything is worth
remembering. Findings are appended to .bifrost/candidates.md in the project
root, which the hook creates git-ignored on first use.
Candidates are local and unreviewed. Nothing is shared until someone promotes it:
/bifrost-candidates # review, promote the good ones, prune the rest
They deliberately do not go straight into shared memory. The corpus has no read
permission model — memory_search takes filters, but they are the caller's own
retrieval narrowing, not an ACL the writer can set — so anything written to it is
recalled by every colleague immediately as settled team knowledge. A mid-session
judgement should not become company-wide fact without a human deciding it should.
What may be promoted, and what has to be redacted or withheld, is set out in
guidance/memory-classification.md; the
/bifrost-candidates triage step applies it.
Nothing is written automatically, and answering "nothing worth recording" is a normal outcome. Delete the file at any time; it regenerates empty.
Marketplace installs need no registration step at all: the plugin ships this
.mcp.json, which Claude Code auto-discovers when the plugin is enabled:
{
"mcpServers": {
"bifrost": {
"type": "http",
"url": "${user_config.gateway_url}",
"headers": { "x-bf-vk": "${user_config.virtual_key}" }
}
}
}
gateway_url and virtual_key come from the plugin's userConfig, which
Claude Code prompts for at install time on every surface (see Registration
and connection modes).
The manual fallback (scripts/install.js, or /bifrost-setup) registers a
separate server at user scope via claude mcp add --scope user; the plugin
never edits Claude Code config files on its own. That path still resolves
${BIFROST_URL} and ${BIFROST_VK} at runtime from Claude Code's
environment (~/.claude/settings.json env key and/or your shell), unlike
the plugin's own .mcp.json above. Without --key, the key is never stored
in any file.
After install, enable, and restart:
/mcp — bifrost should be connected; note tool prefixes (e.g. skills-skill_search)./doctor — no hook-load errors for bifrost-plugin.<prefix><skills-server>-skill_search with a task description — should return matches./bifrost-debug for the full decision tree.401 / 403 from bifrost — BIFROST_VK missing or wrong. Check ~/.claude/settings.json env and restart CC.
Skill-search tool not found — bifrost MCP not loaded, or gateway exposes no skill server. Run /mcp; confirm tool names match BIFROST_SKILLS_SERVER.
Repository skill missing from skill_search / get_skill — skill may be in the Bifrost marketplace but not yet in the MCP index (see Gateway skill discovery vs Bifrost Skills Repository).
/doctor duplicate hooks — fixed in v1.0.1; update the marketplace and reinstall.
Hooks not firing — hooks ship inside the plugin (hooks/hooks.json, auto-loaded by Claude Code). Confirm installed + enabled via /plugin, then restart.
Claude Desktop mcp_registration_failed / OAuth errors — make sure you used the stable gateway URL (not an old ephemeral tunnel link), then run /bifrost-debug in Claude Code for the Desktop decision tree (PRM check, redirect-URI, audience/scope, VK mapping). The plugin itself no longer uses OAuth (since 1.9.0); use a virtual key or auto_login.
Type "bifrost not working" in Claude Code for the guided bifrost-debug diagnosis flow.
BIFROST_VK is always ${BIFROST_VK} in files — never a literal key value..gitignore blocks .env, *.key, and *_VK=* patterns.claude mcp add; without --key it stores the ${BIFROST_VK} template and the key never touches disk.git grep -nE 'vk_[A-Za-z0-9]' to confirm the repo is clean before any push.SessionStart → session-start.cjs → prints guidance/bifrost-context.md (~400 tokens)
UserPromptSubmit → prompt-submit.cjs → skill-discovery hint for task-verb prompts
.mcp.json (shipped) → bifrost MCP server → <prefix><server>-<tool> (skills, memory, …)
Memory: agent calls <prefix><memory-server>-search before tasks,
<prefix><memory-server>-store after significant work.
Tool names. <prefix> depends on how the gateway is connected: mcp__plugin_bifrost-plugin_bifrost__ from the plugin, mcp__claude_ai_luca_Bifrost__ from the claude.ai connector, mcp__bifrost__ from a hand-added server (which hides the plugin's). The injected session context names the one that applies.
All hooks silent-fail: any error exits 0 silently so they never block a prompt.
By default hooks write only to their own cache under ~/.cache/bifrost-plugin/ and
never touch Claude Code configuration, launch other programs, or open browsers.
Two opt-in options, both off by default, change that. With auto_login on, a session
may open the browser once for company sign-in (hooks/auto-setup.cjs) and the key it
gets back is cached in ~/.cache/bifrost-plugin/vk; the sign-in worker also rewrites
this plugin's entry in ~/.claude/mcp-needs-auth-cache.json. With migrate_legacy on,
it runs claude mcp remove for a hand-added bifrost server.
The background cache refresh contacts the gateway at most once per hour
(BIFROST_REFRESH=0 disables it). By default it sends no query at all: session-start
fact priming is off, so the worker only learns which skills and memory tools the
gateway offers. With priming on (BIFROST_MEMORY_PRIME=1) it sends one
memory_search whose query is the git remote's repository name (else the repo
directory name), a ticket key from the branch or directory name, and up to five
words from the branch name. Branch names can carry people's names, for example
phil/LUCA-123-fix-login becomes my-repo LUCA-123 phil fix login, and anything else
typed into a branch name is sent too. Credentials in a remote URL are dropped before
the name is taken. With BIFROST_KB_WING set, the KB recall sends the same query.
# 1. Remove / disable the plugin from Claude Code:
# /plugin (then uninstall bifrost-plugin) — or remove its dir under ~/.claude/plugins
# 2. If you registered the server manually (installer or /bifrost-setup):
claude mcp remove --scope user bifrost
# 3. Remove BIFROST_* from ~/.claude/settings.json env and ~/.zshrc / ~/.bashrc if you added them.
# 4. Optionally clear the plugin cache:
rm -rf ~/.cache/bifrost-plugin
MIT — see LICENSE. Copyright (c) 2026 neXenio GmbH.
See CHANGELOG.md.
Claude Code + Claude Desktop plugin for any Bifrost MCP gateway: one-command setup, skill discovery, agent-driven memory, signed admin policy, and OAuth 2.1 for Desktop.
Tools
Noch keine Tool-Liste. Remote-Server erhalten eine nach dem ersten Health-Check.
FAQ
Kopieren Sie auf dieser Seite die stdio-Konfiguration für Cursor, Claude Desktop, Claude Code oder VS Code. Sie nutzt die Installation des Herausgebers, keinen PlugMCP-Proxy.
In diesem Eintrag ist keine erforderliche Umgebungsvariable aufgeführt.
Bifrost Plugin läuft lokal über stdio.
Zuletzt geprüft: 2026-11-12. Claude Code + Claude Desktop plugin for any Bifrost MCP gateway: one-command setup, skill discovery, agent-driven memory, signed admin policy, and OAuth 2.1 for Desktop.
