RELATED 01
Loki Mode
MCP interface to the Loki Mode coding agent: start runs, read their state and check signed receipts
1.1kGitHub stars
21k/wknpm downloads
79popularity score
Beadhive
MCP front end for bh, the Beadhive CLI that runs beads issue tracking across many git repositories
By beadhive Python Local · stdio ProductivityGit and code hostingDeveloper tools
41 popularity score ★ 30 ↓ 3.0k/mo
Connect your client
Local (PyPI)
Add in one click
Opens the app, which asks before it adds the server.
Or add it by command or config
Claude CodeTerminal
claude mcp add beadhive -- uvx --from beadhive bh-mcpClaude Desktopclaude_desktop_config.json
{
"mcpServers": {
"beadhive": {
"command": "uvx",
"args": [
"--from",
"beadhive",
"bh-mcp"
]
}
}
}Cursor~/.cursor/mcp.json
{
"mcpServers": {
"beadhive": {
"command": "uvx",
"args": [
"--from",
"beadhive",
"bh-mcp"
]
}
}
}VS Code.vscode/mcp.json
{
"servers": {
"beadhive": {
"type": "stdio",
"command": "uvx",
"args": [
"--from",
"beadhive",
"bh-mcp"
]
}
}
}Codex~/.codex/config.toml
[mcp_servers.beadhive]
command = "uvx"
args = ["--from", "beadhive", "bh-mcp"]Gemini CLITerminal
gemini mcp add --scope user beadhive uvx -- --from beadhive bh-mcpWhat it does
Beadhive's `bh` command treats each git repository as a "hive": its own beads issue database (kept in Dolt under the repo's own git remote) with a short prefix. `bh` registers hives, keeps their labels consistent, runs `bd` and `git` across them and builds one view of open work across all of them. The PyPI package `beadhive` also installs `bh-mcp`, a stdio MCP server that hands a small part of that CLI to an assistant.
The makers keep the tool list deliberately short and expect agents to call the CLI for everything else (`bh sync`, `bh doctor`, `hive rm` stay CLI-only). Through MCP an assistant can validate and file a plan spec as an epic of beads, create beads in batches, tidy a bead branch's commits, set one config key, register or onboard a repository as a hive, read hive status, and run a discovered toolchain entrypoint inside a hive's clone. A long list of read-only resources (`beadhive://work/ready`, `beadhive://doctor`, `beadhive://hive/status`, worktree and intake views and more) carries live state, and mutating tools send `resources/updated` so a subscribed client re-reads.
The docs' tool table lists nine tools, but the v0.25.1 source registers ten: `toolchain_exec`, which runs a given argument vector in a hive's main clone and returns its exit code, stdout and stderr, is missing from docs/MCP.md (src/beadhive/kernel/operations/__init__.py, `_MCP_TOOLS`).
What it needs
| Runtime | Python 3.11+ |
|---|
Python 3.11+ and uv (for uvx), on macOS or Linux. `bh` drives `bd` (beads), `dolt`, `gh` and `git-workspace`, which a PyPI install does not bring: the makers' managed path (`nix profile add github:beadhive/beadhive/latest#default`, needs root and nix 2.30+, Apple Silicon only on macOS) installs them pinned; otherwise install them yourself, with `bd` from HEAD (`brew install --HEAD beads`). Run `bh config init` first to create ~/.beadhive.
Limits
Only ten tools; most `bh` commands are CLI-only by design, including `bh sync`, `bh doctor`, `config get` and the destructive `hive rm`. Resource-change notifications fire only for changes made through MCP: edits to ~/.beadhive/config.yaml or `bh`/`bd` commands run in a shell do not notify, so a subscribed client can go stale. The server is long-lived; after upgrading the package, restart the MCP client to pick up the new code. The managed install path is not available on Intel Macs, and Windows is not among the listed platforms.
Who it suits
Teams already running beads issue tracking across several repositories who want an assistant to file plans and beads with structured input rather than shell strings (the makers prefer `bd_create` over the CLI because markdown backticks once ran as shell commands). It is a companion to the `bh` CLI, not a standalone tracker: anyone not using beads, or wanting a hosted issue tracker such as GitHub Issues, has no use for it. Because it can register repositories, change config and run commands in clones, it suits a developer's own machine more than a shared one.
Tools 10
plan_check- Validate a plan spec and report problems, warnings and missing or stubbed acceptance criteria
plan_file- File a plan spec as an epic with its child beads in a hive, with an optional dry run
work_refine- Squash or autosquash a bead branch's commits, keeping a backup, with an optional dry run
bd_create- Create one or more beads in a hive from structured records
config_set- Set one dotted key in the Beadhive config, validated before anything is written
hive_add- Register an existing repository as a hive with a prefix and kind
hive_onboard- Clone, initialise, register and sync a repository as a new hive
hive_status- Show registered hives, unregistered candidates, prefix collisions and violations
hive_list- List repositories that could be registered as hives
toolchain_exec- Run a command vector in a hive's main clone and return exit code, stdout and stderr