Skip to main content
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/{path} proxies any request to the cluster’s Kubernetes API server. The path after /kube/ is forwarded directly, along with query parameters.

​
Pod Logs

Fetch pod logs as plain text — no streaming, no SSE, just the log output: 
async () => {
  const res = await cnap.request({
    method: "GET",
    path: "/v1/clusters/CLUSTER_ID/kube/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/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/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 — by fetching the Kubernetes OpenAPI spec: 
GET /v1/clusters/{id}/kube/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 result as JSON: 
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;
  // { stdout: "PostgreSQL 16.1 ...\n", stderr: "", exit_code: 0 }
}

​
Request Body

FieldTypeDescription
namespacestringKubernetes namespace
podstringPod name
containerstringContainer name within the pod
commandstring[]Command and arguments

​
Response

FieldTypeDescription
stdoutstringStandard output
stderrstringStandard error
exit_codenumberExit code (0 = success)
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

Code Mode in Action

See how agents compose complex operations in a single call

Platform MCP

The MCP server that provides these endpoints