plug - MCP for AI coding agents

MCP: plug for your AI coding agent

What an agent lacks is not the ability to run plug -s …; it is knowing what to run and reading what came of it. Which clusters this machine knows, what doctor finds and the exact remedy, the environment a deployed workload runs with, whether a name exists in the cluster: plug knows all of that, and answered in prose for a person. plug mcp answers with structure, as MCP tools.

It runs over stdio, the way editors launch an MCP server: one process per editor session, nothing listening on a port. It is the plug launcher itself, so one entry covers every profile on the machine, whatever version each cluster runs - the launcher already follows each cluster's agent (see Profiles & versions).

Install it in your agent

The command is plug, the only argument is mcp. Same everywhere:

Claude Code

claude mcp add --scope user plug -- plug mcp

--scope user makes it available in every project; leave it out for the current one, or --scope project to share it through .mcp.json at the project root:

{
  "mcpServers": {
    "plug": { "type": "stdio", "command": "plug", "args": ["mcp"] }
  }
}

Cursor

.cursor/mcp.json in the project, or ~/.cursor/mcp.json for all of them:

{
  "mcpServers": {
    "plug": { "type": "stdio", "command": "plug", "args": ["mcp"] }
  }
}

VS Code (Copilot)

.vscode/mcp.json in the workspace, or the command palette's MCP: Open User Configuration for every workspace. The top-level key is servers, not mcpServers:

{
  "servers": {
    "plug": { "command": "plug", "args": ["mcp"] }
  }
}

Windsurf, and the others

Any client that launches stdio servers takes the same three fields. Windsurf reads mcp_config.json under its config directory with the mcpServers shape above.

plug has to be on the agent's PATH, which is the case once it is installed from a cluster (Getting started). On macOS the launcher is setuid; the MCP server never needs that privilege and never uses it: the tools read, they do not open a tunnel.

The tools

tool	what it answers
`list_profiles`	the clusters this machine knows: name, agent address, update policy, whether a personal key is enrolled
`doctor`	`plug doctor`, check by check: area, name, `ok` / `warn` / `fail`, the detail and the exact remedy. Optionally for one profile
`env_of`	the environment a deployed workload runs with, as a `-s` takeover would hand it to your command (see How it works). Secret-looking values are masked; `reveal: true` asks for them in the clear
`resolve_name`	whether a name exists in the cluster, through the cluster's own DNS: what `-s` would take over, or what a session would reach
`agent_info`	the agent's report: version, backend, image, and on Kubernetes the RBAC grants it probed (`endpoints`, `exec`)

Every tool is a verb the CLI already speaks or the doctor it already runs; nothing is new on the agent side, and an agent older than a verb answers "unknown command", which the tool returns as an error naming the profile to update.

What it looks like from the agent

Ask "why does orders-svc not reach odb when I plug it on prod?" and the agent can read, in order:

doctor on prod: exec grant: warn, "the agent may not exec into pods: a plugged service gets its variables from the pod spec, and those that come from a Secret arrive empty", with the kubectl patch to run;
env_of orders-svc: DB_PASSWORD is in the notes as "empty because it comes from a Secret";
and conclude, and fix the role, without having been told how plug works.

Not yet

Opening a session from a tool (serve / unserve) is not offered yet: a session is a process that lives, and it deserves its own shape. See the roadmap.