The org grant is the boundary that matters: it is chosen at sign-in, enforced on the server rather than in the client, and changing it means signing in again. On top of that, deleting resources, shrinking or deleting volumes, replacing workloads and applying to production all require explicit confirmation, and secret values never leave the platform. Codex users have one extra step — plugin hooks are off by default there, and the guardrail rule needs them on.
Control Plane's official plugin. It pairs the hosted Control Plane MCP server with domain skills and two guided agents, so an assistant can operate workloads with verified `cpln` commands instead of improvising them.
- Live tools against the hosted Control Plane server, scoped to the organizations you grant
- Domain skills across CLI usage, access control, autoscaling, networking, observability, migration, templates, stateful storage and security
- Two guided agents: workload troubleshooting, and migration from Kubernetes, Compose or Helm
- An always-on guardrail rule applied in every session
- In Claude Code, two of the workflows also have slash commands — `/cpln:troubleshoot` and `/cpln:migrate-k8s`; other clients ask for them by name
- Secrets surface as metadata only — values are never returned through the tools
For a supported client, install the plugin: `/plugin marketplace add https://github.com/controlplane-com/ai-plugin.git` then `/plugin install cpln@controlplane` in Claude Code, `codex plugin marketplace add` for Codex, or `agy plugin install` for Antigravity CLI. Any other client points at the hosted server: https://mcp.cpln.io/mcp. Authentication is OAuth 2.1 with PKCE — you pick which organizations it may operate on, and the grant is enforced server-side on every call. CPLN_TOKEN, CPLN_ORG, CPLN_GVC and CPLN_PROFILE are only needed for the `cpln` CLI workflows some skills generate.
Build from source — clone the repository and build it, then deploy it and point your client at the endpoint