Act as MCP server

MCP-server support — this is what matters for "keep agents warm and call them on demand from any CLI".

Use case: You start all your CLI on the same folder. They now have access to the same code base.
The CLI you work in can now ask any CLI to review code or do other tasks through MCP.
I have noticed that Claude Code can not review its own code properly. It is always CoPilot that finds the bugs late in the workflow when the code is already on GitHub.
I would like to ask the other CLI their opinion early in the workflow.

## Built-in MCP server support

| CLI | Built-in MCP server? | Command |
|----------------|----------------------|------------------|
| Claude Code | Yes | claude mcp serve |
| Codex | Yes | codex mcp-server |
| Junie | No | — |
| Vibe (Mistral) | No | — |
| Copilot CLI | No | — |

**Important distinction**: Junie, Vibe, and Copilot CLI all consume MCP servers (they're MCP clients), but none of them expose themselves as an MCP server that another agent could call.

## What this means
Codex and Claude Code can be kept warm and called from another agent today, with no custom code.

Junie, Vibe, Copilot CLI can only be called via subprocess (vibe -p ..., junie --task ..., copilot ...) — which is what we're trying to avoid because it pays cold-start every call.

## Next steps
If we want all agents warm-and-callable from any CLI, the only built-in path is to file feature requests upstream:

* JetBrains — add junie mcp-server mode to Junie CLI
* Mistral — add vibe mcp-server mode to Vibe / Mistral Code
* GitHub — add copilot mcp-server mode to Copilot CLI

Until then, only Codex and Claude Code qualifies.