This PR fixes three bugs that prevented the MCP plugin from working:
1. **Fixed parameter name mismatch in tools.py**
- Changed `workspace_root=workspace_root` to `working_dir=workspace_root`
- The `create_bd_client()` function expects `working_dir` parameter,
but tools.py was passing `workspace_root`
- This caused "got an unexpected keyword argument 'workspace_root'" error
2. **Added version check guard for daemon client**
- Added `hasattr(_client, '_check_version')` check before calling
- BdDaemonClient doesn't have `_check_version()` method, only BdCliClient does
- This caused "'BdDaemonClient' object has no attribute '_check_version'" error
3. **Implemented proper daemon socket detection for fallback**
- Added synchronous socket file existence check before creating daemon client
- Walks up directory tree looking for `.beads/bd.sock` file
- Only creates daemon client if socket exists, otherwise falls back to CLI
- Previously, daemon client was created but failed on first method call
- This enables the documented "prefer_daemon with automatic CLI fallback" behavior
**Testing:**
- Verified MCP tools work correctly with single-repo setup
- Confirmed automatic fallback to CLI when daemon isn't running
- Tested on macOS with bd v0.9.9
**Related Issues:**
- Addresses symptoms similar to #65 (Windows BEADS_WORKING_DIR issue)
Since our implementation uses `async` IO for subprocess communication, it's
crucial to utilize the `fastMCP.run_async()` entry-point of FastMCP.
This should fix crashes on Windows.
ref: steveyegge/beads#53
- MCP server now uses daemon client by default with CLI fallback
- Added BEADS_USE_DAEMON environment variable (default: enabled)
- Created multi-repo integration test (all tests pass)
- Updated .gitignore for daemon runtime files
- Added SETUP_DAEMON.md with migration instructions
- Closed bd-105 (investigation complete) and bd-114 (multi-server confusion)
This enables single MCP server to handle multiple repos via daemon
with per-request context routing. No more multiple MCP server configs!
Amp-Thread-ID: https://ampcode.com/threads/T-c222692e-f6ef-4649-9726-db59470b82ef
Co-authored-by: Amp <amp@ampcode.com>
- Added per-request storage routing in daemon server
- Server now supports Cwd field in requests for database discovery
- Tree-walking to find .beads/*.db from any working directory
- Storage caching for performance across requests
- Created Python daemon client (bd_daemon_client.py)
- RPC over Unix socket communication
- Implements full BdClientBase interface
- Auto-discovery of daemon socket from working directory
- Refactored bd_client.py with abstract interface
- BdClientBase abstract class for common interface
- BdCliClient for CLI-based operations (renamed from BdClient)
- create_bd_client() factory with daemon/CLI fallback
- Backwards-compatible BdClient alias
Next: Update MCP server to use daemon client when available
- Remove ~/.beads/default.db fallback from FindDatabasePath()
- Update daemon to error if no database found instead of falling back
- Update main.go to require explicit database initialization
- Add help/version/quickstart to commands that don't need database
- Add MCP client debug logging for database routing
Amp-Thread-ID: https://ampcode.com/threads/T-2b757a14-cf10-400e-a83c-30349182dd82
Co-authored-by: Amp <amp@ampcode.com>
Implements the `bd` reopen command across the entire MCP stack, enabling
agents to reopen closed issues with optional reason tracking for audit
trails. This addresses the need to handle regressions and incorrectly
closed issues without manual `bd` CLI intervention.
The reopen command is more explicit than `bd update --status open` and
emits a dedicated Reopened event in the audit log, making it easier to
track why issues were reopened during analysis.
Changes:
- `models.py`: Add ReopenIssueParams with issue_ids list and optional reason
- `bd_client.py`: Implement reopen() method with JSON response parsing
- `tools.py`: Add beads_reopen_issue() wrapper with Annotated types for MCP
- `server.py`: Register 'reopen' MCP tool with description and parameters
Testing (10 new):
- `test_bd_client.py`: 4 unit tests (mocked subprocess)
- `test_bd_client_integration.py`: 3 integration tests (real `bd` CLI)
- `test_mcp_server_integration.py`: 3 MCP integration tests (FastMCP Client)
- `test_tools.py`: 3 tools wrapper tests (mocked BdClient)
Also updated `README.md`.
1. Fix `test_default_beads_path_auto_detection`
- Changed beads_path to use `Field(default_factory=_default_beads_path)` so the default is evaluated at instance
creation time, not class definition time
- Updated test to mock both `shutil.which` and `os.access`
2. Fix `test_init_creates_beads_directory`
- Fixed test to pass `working_dir=temp_dir` to `BdClient` instead of using `os.chdir()`
- The `_get_working_dir()` method checks `PWD` env var first, which isn't updated by `os.chdir()`
3. Fix minor linting errors reported by `ruff` tool
4. Update `beads` version to `0.9.6` in `uv.lock` file
MCP Server test coverage is now excellent, at 92% overall maintaining our high-standards of production level quality.
```
Name Stmts Miss Cover
------------------------------------------------
src/beads_mcp/__init__.py 1 0 100%
src/beads_mcp/__main__.py 3 3 0%
src/beads_mcp/bd_client.py 214 14 93%
src/beads_mcp/config.py 51 2 96%
src/beads_mcp/models.py 92 1 99%
src/beads_mcp/server.py 58 16 72%
src/beads_mcp/tools.py 59 0 100%
------------------------------------------------
TOTAL 478 36 92%
```
Added a debug tool that reports:
- os.getcwd() value
- PWD environment variable
- BEADS_WORKING_DIR environment variable
- Other relevant environment variables
This will help diagnose where bd commands are running from and whether
Claude Code sets PWD or other variables correctly.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
The MCP server was running bd commands from the plugin installation directory,
causing the database to be created in the wrong place.
Added BEADS_WORKING_DIR config option and modified BdClient to use working
directory for subprocess calls. Falls back to PWD environment variable.
This ensures bd commands run from the user's actual project directory.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Prepared the beads-mcp package for publishing to PyPI, simplifying installation
for users who want to use the MCP server with Claude Desktop or other MCP clients.
Changes:
- Added LICENSE file (MIT) to integrations/beads-mcp/
- Updated pyproject.toml with PyPI metadata (license, URLs, classifiers)
- Updated README with simplified installation (uv tool install beads-mcp)
- Created PYPI.md with detailed publishing guide
- Updated examples/claude-desktop-mcp/README to reference the production MCP server
Installation is now simplified from:
git clone && cd && uv sync
to:
uv tool install beads-mcp
Configuration is simplified from multi-line with --directory args to:
"command": "beads-mcp"
Tested build successfully. Package ready for:
- Test PyPI: python -m twine upload --repository testpypi dist/*
- Production PyPI: python -m twine upload dist/*
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add helpful installation instructions when bd CLI is not found,
making it clear that the CLI must be installed separately.
Changes:
- Add BdNotFoundError.installation_message() with clear install steps
- Update all BdNotFoundError raises to use new formatted message
- Improve config error message with installation instructions first
- Update tests to match new error message format
Error message now shows:
- Clear explanation that bd CLI is required
- Installation command with curl one-liner
- Link to GitHub installation docs
- Reminder to restart Claude Code after installation
Test results: 90/91 tests passing (1 unrelated path assertion)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The MCP server was running all bd commands in its own installation directory
(~/.claude/plugins/marketplaces/beads-marketplace/integrations/beads-mcp/)
instead of the user's project directory. This caused databases to be created
in the wrong location.
For example, when working in ~/ai/flutter/wyvern and running `bd init --prefix wy-`,
the database was created at:
~/.claude/plugins/marketplaces/beads-marketplace/integrations/beads-mcp/.beads/wy-.db
Instead of the expected location:
~/ai/flutter/wyvern/.beads/wy-.db
Solution:
- Add `cwd=os.getcwd()` to all asyncio.create_subprocess_exec() calls
- This makes bd commands execute in the current working directory from PWD env var
- Claude Code updates PWD for the MCP server process environment
Impact:
- bd init now creates .beads/ in the correct project directory
- All bd commands (create, list, update, etc.) operate on the correct database
- Multi-project workflows work correctly without manual DB path configuration
Test results: 90/91 tests passing (1 unrelated path assertion failure)
Critical bug: MCP init tool reported success but didn't create .beads
directory. It was using --db flag which tells bd to use an existing
database elsewhere instead of creating a new one.
Root cause:
- bd_client.init() was calling _global_flags() which adds --db flag
- bd init --db <path> uses existing db instead of creating new one
- Result: init appeared to succeed but created nothing
Fix:
- Remove _global_flags() from init command
- Only pass --actor flag (safe for init)
- Do NOT pass --db flag to init (defeats the purpose)
- Add explicit comment explaining why
Testing:
- Added test_init_creates_beads_directory() integration test
- Verifies .beads directory is created in current working directory
- Verifies database file has correct prefix
- All 91 tests pass
This was causing silent failures where agents thought they initialized
bd but the .beads directory was never created.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes issue where MCP tools failed with "bd executable not found"
when BEADS_PATH was set to command name instead of absolute path.
Changes:
- Remove BEADS_PATH=bd from plugin.json (use auto-detection)
- Enhance config validator to resolve command names via PATH
- Add comprehensive config validation tests (11 new tests)
The validator now accepts both:
- Absolute paths: /usr/local/bin/bd
- Command names: bd (resolved via shutil.which)
This makes the MCP server more robust and user-friendly while
maintaining backward compatibility.
All 90 tests pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes MCP server hanging when bd executable is not found at default path.
Problem:
- Config validation used sys.exit(1) on failure
- sys.exit() hangs in async MCP server context (doesn't properly terminate)
- Default bd path was hardcoded to ~/.local/bin/bd
Solution:
1. Use shutil.which() to find bd in PATH before falling back to default
2. Raise ConfigError instead of calling sys.exit()
3. MCP server now properly fails with error message instead of hanging
This fixes the multi-minute hang when trying to use MCP tools if bd is
installed in a non-default location (e.g., /usr/local/bin/bd).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes Claude Code marketplace plugin installation failure (bd-183).
Problem: The plugin.json manifest included an engines field (borrowed from npm)
to specify minimum bd CLI version requirements. However, Claude Code's plugin
manifest schema doesn't recognize this field, causing validation errors when
installing via /plugin marketplace add.
Solution:
1. Remove the engines field from plugin.json
2. Add runtime version checking in the MCP server startup
3. Update documentation to reflect automatic version checking
Changes:
- .claude-plugin/plugin.json: Remove unsupported engines field
- integrations/beads-mcp/src/beads_mcp/bd_client.py:
- Add BdVersionError exception class
- Add _check_version() method to validate bd CLI >= 0.9.0
- Use bd version command (not bd --version)
- integrations/beads-mcp/src/beads_mcp/tools.py:
- Make _get_client() async to support version checking
- Update all tool functions to await _get_client()
- Add version check on first MCP server use
- .claude-plugin/commands/bd-version.md: Update to mention automatic checking
- PLUGIN.md: Document automatic version validation at startup
Benefits:
- Plugin installs successfully via Claude Code marketplace
- Clear error messages if bd CLI version is too old
- Version check happens once per MCP server lifetime (not per command)
- Users get actionable update instructions in error messages
Closes bd-183
Issue found: bump-version.sh was missing the MCP server's __init__.py file, causing version mismatches (pyproject.toml: 0.9.2, __init__.py: 1.0.0).
Changes:
- Add integrations/beads-mcp/src/beads_mcp/__init__.py to update list
- Add it to git staging in auto-commit
- Add it to verification check
- Fix current version mismatch: 1.0.0 to 0.9.2
Now the script updates 7 files instead of 6
Fixes version inconsistencies across the project. All components now at 0.9.2:
Updated:
- .claude-plugin/plugin.json: 0.9.0 → 0.9.2
- .claude-plugin/marketplace.json: 0.9.0 → 0.9.2
- integrations/beads-mcp/pyproject.toml: 1.0.0 → 0.9.2
- README.md: v0.9.0 → v0.9.2
- PLUGIN.md: Updated version requirements
Root cause: Previous version bumps (0.9.0 → 0.9.1 → 0.9.2) only updated
cmd/bd/version.go, leaving other components out of sync.
The MCP server was initially versioned at 1.0.0 when added today, but
syncing to 0.9.2 for consistency since the project is still in alpha.
Closes bd-66
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
