The Model Context Protocol (MCP) is an open standard that lets AI coding assistants connect to external tools and services. Think of it like USB for AI agents: a universal interface that works regardless of which IDE or model you use.
Before MCP, every AI tool had its own proprietary plugin system. Want to give Claude access to your database? Build a Claude plugin. Want the same for Cursor? Build a different integration. MCP changes that. One server, many clients.
For orchestration, MCP is transformative. It means an orchestration tool can expose its capabilities once and work everywhere: Claude Code, Cursor, Windsurf, or any future MCP-compatible client.
A single AI agent can write a function. It can refactor a file. But real-world development tasks rarely fit inside a single file or a single prompt.
Consider adding authentication to an application. You need to create database migrations, write auth middleware, build login/signup routes, update the frontend, add tests, and update documentation. A single agent doing this sequentially might take 30 minutes and lose context halfway through.
With orchestration, you split this into parallel streams of work. The database migration runs alongside the middleware. Route handlers start as soon as both are done. Tests run in parallel with documentation. What took 30 minutes now takes 8.
But parallelism is dangerous without guardrails. Two agents editing the same file produces corrupt output. Dependencies between tasks need explicit management. Errors in one stream can cascade into others.
This is the problem an orchestrator solves.
orchex exposes 12 MCP tools that give your AI assistant full orchestration capabilities. When you connect orchex as an MCP server, your IDE gains the ability to plan, parallelize, and execute multi-agent workflows.
Here is a typical MCP configuration for Claude Code in your project's .mcp.json:
{
"mcpServers": {
"orchex": {
"command": "npx",
"args": ["-y", "@wundam/orchex@latest"]
}
}
}That is it. No API keys for the orchestrator itself, no account creation, no configuration files. orchex runs locally and uses your existing LLM API keys through environment variables.
Once connected, your AI assistant can call tools like init, add_stream, execute, and auto to manage multi-agent workflows directly from your conversation.
Before diving into a practical example, three concepts matter:
Streams are independent units of work. Each stream has a goal, a list of files it owns (can modify), and a list of files it reads (can reference). File ownership is enforced at the artifact level, so parallel streams cannot corrupt each other's work.
Waves are groups of streams that execute in parallel. orchex analyzes dependencies between streams and organizes them into waves automatically. Streams within a wave run concurrently. The next wave starts only when the current wave completes.
Plans are the bridge between your intent and execution. You describe what you want in natural language, and orchex generates a structured plan with streams, dependencies, and file ownership.
Let us walk through orchestrating a real task: adding a notification system to a Node.js application.
Tell your AI assistant what you want:
"Use orchex to add an email notification system. I need a notification service, email templates, a queue for async delivery, and API endpoints to manage notification preferences."
The assistant calls the auto tool, and orchex produces a plan with streams like this:
streams:
- id: notification-types
goal: "Create TypeScript types for notifications, templates, and delivery status"
owns:
- src/notifications/types.ts
reads:
- src/types/user.ts
deps: []
- id: notification-service
goal: "Implement core notification service with template rendering"
owns:
- src/notifications/service.ts
- src/notifications/templates.ts
reads:
- src/notifications/types.ts
- src/config/email.ts
deps: [notification-types]
- id: notification-queue
goal: "Add async delivery queue with retry logic"
owns:
- src/notifications/queue.ts
- src/notifications/worker.ts
reads:
- src/notifications/types.ts
- src/notifications/service.ts
deps: [notification-service]
- id: notification-api
goal: "Create REST endpoints for notification preferences"
owns:
- src/routes/notifications.ts
reads:
- src/notifications/types.ts
- src/notifications/service.ts
- src/auth/middleware.ts
deps: [notification-service]orchex analyzes the dependency graph and organizes execution into waves:
notification-types (no dependencies, runs first)notification-service (depends on types)notification-queue and notification-api (both depend on service, run in parallel)Each stream in a wave runs as an independent LLM call. orchex passes the stream's goal, the contents of its reads files for context, and strict boundaries on which files it can modify.
If notification-queue tries to modify src/notifications/service.ts, the artifact is rejected. Only notification-service owns that file.
When all waves complete, orchex produces an execution report. If a stream fails (LLM generates invalid code, syntax error, missing import), the self-healer kicks in. It categorizes the error, generates a fix stream with the right context, and retries up to 3 times.
The traditional approach to multi-agent systems involves building custom frameworks with proprietary APIs. MCP orchestration is different in three ways.
First, it is IDE-native. You do not switch to a separate tool or terminal. The orchestration happens inside your existing conversation with your AI assistant.
Second, it is model-agnostic. orchex supports six LLM providers: Claude, OpenAI, Gemini, DeepSeek, Ollama, and AWS Bedrock. Different streams can use different models based on their strengths.
Third, it is safe by default. File ownership enforcement, dependency resolution, and self-healing are built into the protocol, not bolted on as afterthoughts.
The fastest way to try MCP orchestration is to add orchex to your IDE:
For Claude Code, add the config shown above to .mcp.json in your project root.
For Cursor, add this to your MCP settings:
{
"mcpServers": {
"orchex": {
"command": "npx",
"args": ["-y", "@wundam/orchex@latest"]
}
}
}Then ask your assistant to run a multi-stream task. Start small: a two-stream refactor to see waves in action. Once you see parallel execution with file safety, you will not want to go back to serial prompting.
Check the orchex documentation for detailed guides on stream definitions, learning configuration, and provider setup.