Most AI assistants can describe your infrastructure but can’t operate it — it’s scattered across Terraform repos, tickets, consoles and half-deprecated CLIs, with no single interface an agent can act on. KDP is different: it exposes one Kubernetes-native API surface, and — as Kubermatic’s Giving AI Hands article puts it — “anything you do in the UI, you can do through the API.” That single API surface is what makes KDP agent-ready: an AI assistant can discover it and act on it.
KDP ships a set of agent skills and a hosted MCP server that let you drive a KDP environment from an AI coding assistant such as Claude Code or OpenCode — browsing the service catalog, creating resources, checking status, and authoring Blueprints, in plain language.
This is separate from the dashboard’s own AI assistance, which generates resource specs and forms inside the dashboard. The tooling here runs in your local AI assistant against your KDP workspace.
Because every KDP service is a real Kubernetes API, an assistant can drive the same workflows a human would:
The following KDP skills are available for AI assistants:
kubectl under the
hood but hides the internal terminology and talks to you in plain language.BlueprintDefinition, validating,
publishing, and smoke-testing an instance.The kdp, kdp-kubectl and kdp-blueprints skills each require kubectl pointing at a KDP
workspace (kdp-blueprints also needs the blueprints.kdp.k8c.io API and the services you
want to compose already bound).
KDP hosts the mcp-kdp MCP server behind a gateway on the platform’s public API domain, so
there is nothing to install and no kubeconfig to manage. The gateway authenticates you
with your normal platform account through a browser login, and every call then acts as you,
with exactly your permissions.
Add it to Claude Code:
claude mcp add --transport http \
--client-id kdp-mcp \
--callback-port 19876 \
kdp https://public.api.<your-kdp-domain>/mcp
Or commit it to a repository as .mcp.json, so everyone working on it shares the same server:
{
"mcpServers": {
"kdp": {
"type": "http",
"url": "https://public.api.<your-kdp-domain>/mcp",
"oauth": { "clientId": "kdp-mcp", "callbackPort": 19876 }
}
}
}
For OpenCode, use opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"kdp": {
"type": "remote",
"url": "https://public.api.<your-kdp-domain>/mcp",
"enabled": true,
"oauth": { "clientId": "kdp-mcp" }
}
}
}
Then start the assistant and complete the browser login when prompted.
The dashboard generates these snippets pre-filled with your environment’s URL under Connect an AI agent in the user menu, which is the easiest way to get the endpoint right.
Two settings must be left as generated. Do not change the callback port — the matching
redirect URI is pre-registered with the identity provider, which matches it exactly, so any
other port is rejected at login. Do not pin OAuth scopes — the gateway advertises the
scopes it needs, including a dynamic scope that makes kcp accept the token. Setting
oauth.scopes in Claude Code overrides that and breaks authorization (in OpenCode,
oauth.scope is ignored in favour of the gateway’s).
The server exposes twelve tools covering both the platform and the resource layer, so no second Kubernetes MCP server is needed:
| Tool | Purpose |
|---|---|
listServiceCatalog | Browse the services visible from a workspace. |
getServiceCatalogEntry | Resource schemas, permission claims and status for one service. |
listWorkspaces | Child workspaces of a given path, with type, phase and URL. |
getWorkspaceInfo | A workspace’s path and cluster host URL. |
getServiceKubeconfig | A kubeconfig blob for a workspace’s service endpoint. |
listAvailableApis | Resource kinds usable in a workspace (internal platform APIs excluded). |
getApiSchema | The OpenAPI schema for a kind — worth reading before creating anything. |
listResources / getResource | Read resources, optionally filtered by namespace or labels. |
createResource / updateResource | Apply a YAML or JSON manifest. |
deleteResource | Remove a resource by kind and name. |
The server is stateless: there is no “current workspace” and no way to switch into one.
Every tool takes an explicit workspace path such as root:demo or root:org:team, so tell
your assistant which workspace you mean. It can discover children of a path it already knows
with listWorkspaces.
kdp-kubectl skill. An agent can browse the
catalog and work with services that are already enabled.kdp-blueprints skill.getResource returns the full object
including status and conditions, which covers most troubleshooting; beyond that you need
kubectl.Both give an assistant the ability to act on KDP; they differ in what you have to set up and how wide the surface is:
kubectl they can reach anything your
user can — including enabling services and authoring Blueprints.Use the MCP server for day-to-day work with resources, and a kubectl-based skill when you
need the operations the tools deliberately leave out. The kdp-mcp skill combines the two by
teaching the assistant how to use the MCP tools well.
An agent is not a new security surface. It uses the same API and RBAC as a human user — there is no separate, more-privileged path:
An agent handed a kubeconfig scoped to a workspace likewise inherits that workspace’s boundaries — nothing extra to configure.