Kubernetes access

Give AI agents direct access to cluster resources through the Kubernetes API proxy and command execution

The platform MCP server includes a transparent Kubernetes API proxy and a command execution endpoint. Together, they let agents read pod logs, list resources, inspect deployments, discover CRDs, and run commands, all through the same cnap.request() interface.

These endpoints are accessed through the Platform MCP server’s execute tool. The agent writes JavaScript that calls cnap.request().

Kube API proxy

GET /v1/clusters/{id}/kube_proxy/{path} proxies any request to the cluster’s Kubernetes API server. The path after /kube_proxy/ is forwarded directly, along with query parameters.

Pod logs

Fetch pod logs as plain text:

async () => {
  const res = await cnap.request({
    method: "GET",
    path: "/v1/clusters/CLUSTER_ID/kube_proxy/api/v1/namespaces/NAMESPACE/pods/POD_NAME/log",
    query: { tailLines: "100" }
  });
  return res.body;
}

List resources

List pods, deployments, configmaps, services, or any Kubernetes resource:

async () => {
  // List pods in a namespace
  const res = await cnap.request({
    method: "GET",
    path: "/v1/clusters/CLUSTER_ID/kube_proxy/api/v1/namespaces/default/pods"
  });
  return res.body.items.map(p => ({
    name: p.metadata.name,
    status: p.status.phase
  }));
}

async () => {
  // List deployments
  const res = await cnap.request({
    method: "GET",
    path: "/v1/clusters/CLUSTER_ID/kube_proxy/apis/apps/v1/namespaces/default/deployments"
  });
  return res.body.items.map(d => ({
    name: d.metadata.name,
    replicas: d.status.readyReplicas + "/" + d.spec.replicas
  }));
}

API discovery

Agents can discover cluster-specific APIs (including CRDs) by fetching the Kubernetes OpenAPI spec:

GET /v1/clusters/{id}/kube_proxy/openapi/v3

This is useful when the agent needs to work with custom resources it hasn’t seen before. It can inspect the spec, find the right API group and version, then make calls.

Supported methods

The proxy supports all HTTP methods (GET, POST, PUT, PATCH, DELETE), so agents can also create and modify resources when needed.

Command execution

POST /v1/clusters/{id}:exec runs a command in a pod container and returns the combined output:

async () => {
  const res = await cnap.request({
    method: "POST",
    path: "/v1/clusters/CLUSTER_ID:exec",
    body: {
      namespace: "default",
      pod: "postgres-0",
      container: "postgresql",
      command: ["psql", "-c", "SELECT version();"]
    }
  });
  return res.body;
  // { output: "PostgreSQL 16.1 ...\n", exit_code: 0, duration_ms: 142 }
}

Request body

Field	Type	Required	Description
namespace	string	Yes	Kubernetes namespace
pod	string	Yes	Pod name
container	string	No	Container name within the pod
command	string[]	Yes	Command and arguments

Response

Field	Type	Description
output	string	Combined command output (stdout and stderr)
exit_code	integer	Exit code (0 = success)
duration_ms	number	Execution time in milliseconds

Exec is non-interactive (no TTY, no stdin) with a 30-second timeout. For interactive shells, use the dashboard terminal.

Security

• Authentication is handled server-side. Agents cannot read or set the Authorization header.
• Authorization checks workspace membership before proxying any request.
• All code runs in a sandboxed V8 isolate with no access to the filesystem, network, or Node.js APIs.
• The kube proxy has a 30-second timeout per request.
• Exec commands have a 30-second timeout and are non-interactive.

Related topics

Code Mode in action

See how agents compose complex operations in a single call.

Platform MCP

The MCP server that provides these endpoints.

CRD discovery

Discover and interact with custom Kubernetes resources.

Incident debugging

Full SRE triage using pod health, events, logs, and rollout history.