Integrations
Seven MCP hosts. Three framework adapters. One canonical manifest.
Bulla operates wherever tool definitions live. MCP hosts are auto-detected from their config file paths; framework adapters normalize programmatic tool definitions into the same canonical manifest format.
MCP hosts
Auto-detection walks every registered host. The first config found wins. Pass --host NAME to bulla auditto override; run bulla hosts list to see what was detected on the current system.
| Host | Config path(s) | Notes |
|---|---|---|
Cursorcursor | ~/.cursor/mcp.json · .cursor/mcp.json (workspace) | Top-level mcpServers. Workspace-level config takes precedence over user-level. |
Claude Codeclaude-code | ~/.claude/settings.json · .claude/settings.json (workspace) | Top-level mcpServers or nested mcp.servers. Cross-platform. |
Clinecline | <editor>/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json | Same extension scanned across 5 VS Code forks: Code, Code Insiders, Cursor, Windsurf, VSCodium. Multi-install setups surface every match. |
Claude Desktopclaude-desktop | ~/Library/Application Support/Claude/... (macOS) · ~/.config/Claude/... (Linux) · %APPDATA%/Claude/... (Windows) | Top-level mcpServers. Cross-platform. |
Zedzed | ~/.config/zed/settings.json · %APPDATA%/Zed/settings.json (Windows) | Servers are nested under context_servers, not mcpServers. |
Windsurfwindsurf | ~/.codeium/windsurf/mcp_config.json | Top-level mcpServers. Cross-platform via the Codeium config dir. |
OpenAI Codexcodex | ~/.codex/config.toml · .codex/config.toml (workspace, trusted projects) | TOML format with [mcp_servers.<name>] tables. The only non-JSON host today. |
$ bulla hosts list
$ bulla audit # auto-detect
$ bulla audit --host claude-code # force a specific host
$ bulla audit --host zed cfg.jsonFramework adapters
Frameworks declare tools programmatically rather than via static config. Bulla’s adapters use AST parsing — no code execution — to extract tool definitions and emit a Bulla manifest. Static analysis catches the common patterns; tools registered dynamically (in for-loops, via metaprogramming) will be caught by a future runtime mode that the adapter protocol already reserves.
| Framework | Source | Patterns extracted |
|---|---|---|
Anthropic Messages APIanthropic-messages | .json (array or {tools: [...]}) · .py (top-level tools = [...] literal) | Direct mapping from {name, description, input_schema} dicts. |
LangGraph / LangChainlanggraph | Python source (file or directory) | @tool, @tool("name"), BaseTool subclass with class attributes, StructuredTool.from_function(...) |
CrewAIcrewai | Python source (file or directory) | @tool, @tool("name"), BaseTool subclass with name/description/args_schema |
$ bulla frameworks list
$ bulla import langgraph workflow.py --out manifest.json
$ bulla import crewai agents/ --audit
$ bulla import anthropic-messages tools.json --auditOptional dependencies
Core pip install bulla has no framework dependencies. Static AST parsing uses the standard library only. Extras enable schema-validation helpers and reserve the dependency surface for future runtime support:
$ pip install bulla[langgraph]
$ pip install bulla[crewai]
$ pip install bulla[all]Adding an integration
Both registries follow the same pattern: drop a new module that registers itself at import time. See bulla/docs/HOSTS.md and bulla/docs/FRAMEWORKS.md in the repo for the protocol and a worked example.
For high-value targets not yet covered — Cody, Aider, Goose, Roo Code, Continue, AG2/AutoGen, Mastra, LlamaIndex, Pydantic AI — the protocol is designed so adapters are typically one new file plus a fixture and test. Contributions welcome.