---
title: "MCP"
description: "How executor uses MCP both as an adapter 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 an adapter 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 adapter instead of being flattened into a generic HTTP execution model.

## 2. Executor can expose itself as an MCP server

This is the outward-facing side of MCP.

`packages/hosts/mcp` and the `/mcp` route in `packages/platform/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/sources/mcp` owns MCP tool loading and invocation helpers
- `packages/hosts/mcp` owns the local MCP server surface
- `packages/platform/server` mounts the `/mcp` handler

## Why MCP stays flexible in this model

Because MCP keeps its own adapter/runtime behavior, executor can support protocol-specific features such as sessions, elicitation, and resume without bending the generic imported-tool model to fit them.

That is the main reason MCP is a first-class category in the architecture.