Orchestra MCP — plugin infrastructure for agentic development
An MCP framework where the tools an agent can use are plugins that register themselves, running locally across IDEs and platforms.
The problem
Every agent tool tends to arrive as its own server, with its own transport, config and lifecycle, and each IDE wires them up differently. Adding a capability means editing a monolith, and running it means trusting a remote service with the repository you are working in.
What I did
- IDE
- orchestra serve
- Orchestrator
- Plugins
- Tools
One command starts the stdio MCP server: it finds its sibling binaries, generates a plugin config, boots the orchestrator, waits for every plugin to register, then passes stdin and stdout through to the client. Tools are grouped into packs, so an IDE gets a curated surface rather than hundreds of undifferentiated calls.
Technical detail
Plugins register themselves
The orchestrator boots each plugin as a process and waits for it to announce its tools, so a new capability is a binary beside the others rather than a change to the core.
Local by default
It runs on the developer's machine over stdio, so the code being worked on does not leave it — the same reason the site's own agents talk to local servers rather than hosted ones.
One surface, many clients
Because the transport is plain MCP over stdio, the same tool set answers whichever client is in front of it, and the published figures for the framework are 300+ tools across 38 plugins, 9 IDEs and 6 platforms.
Where it stands
Orchestra MCP is published with its own site, CLI and plugin-development guide. The tool, plugin, IDE and platform counts above are the project's own published figures.
All projects