---title: "MCP"description: "How executor uses MCP both as a source family and as an external interface."--- MCP shows up in executor in two different ways. ## 1. Executor can connect to MCP servers This is the source side of MCP. When a user connects an MCP endpoint, executor treats it as a source family with MCP-specific connection, discovery, and invocation behavior. The control plane persists the binding and credential state, while MCP-specific execution behavior lives behind the adapter and codemode layers. This is why MCP is modeled as its own broad family instead of being treated like just another HTTP format. ## 2. Executor can expose itself as an MCP server This is the outward-facing side of MCP. `packages/executor-mcp` and the `/mcp` route in `packages/server` let external MCP clients talk to the local executor runtime. That means external MCP hosts can: - discover executor tools- trigger executions- resume paused interactions- work against the same local workspace state as the CLI and browser UI ## Why the distinction matters These two roles are related, but they are not the same thing: - inbound MCP means executor is acting as a client to a remote MCP server- outbound MCP means executor is acting as a server for external MCP clients Keeping that distinction clear avoids collapsing very different responsibilities into one vague "MCP integration" concept. ## Where the logic lives Broadly: - control plane owns workspace state, bindings, credentials, and execution lifecycle- `packages/codemode-mcp` owns MCP tool loading and invocation helpers- `packages/executor-mcp` owns the local MCP server surface- `packages/server` mounts the `/mcp` handler ## Why MCP stays flexible in this model Because MCP is handled as a family with its own adapter/runtime behavior, executor can support protocol-specific features such as sessions, elicitation, and resume without bending the generic `http_api` model to fit them. That is the main reason MCP is a first-class category in the architecture.