Provider REST API

12 actions

Connect Claude to Kubernetes

Inspect pods, deployments, nodes and events on a cluster, and read pod logs. Toolspoke puts 12 of its actions behind one MCP endpoint that Claude, Cursor, and Codex all speak.

Connect View pricing

Connection: Provider REST API
Authentication: Service account token
Actions exposed: 12
Cost per call (typical): 1 credit
Adapter: Maintained by Toolspoke

Connected in three steps

1
Install Kubernetes
Open the marketplace in your workspace, add Kubernetes to the project your agents work in, and it appears on the gateway immediately.
2
Connect the credential
Authenticate with service account token. Where to get one, and what it has to be able to reach, is the next section.
3
Point your agent at the gateway
Give your client one address, https://toolspoke.com/mcp. Claude Code takes it as a command, Claude and Claude Desktop add it as a custom connector, and Cursor, Codex and VS Code each read it from a config file of their own.

.mcp.json

{
  "mcpServers": {
    "toolspoke": {
      "type": "http",
      "url": "https://toolspoke.com/mcp"
    }
  }
}

One block covers every tool you have installed. Kubernetes shows up in the client as soon as your policy allows it, and so does everything else you install later.

Where the address goes, per client

Claude Code: Run it in your project, then /mcp to sign in
claude mcp add --transport http toolspoke https://toolspoke.com/mcp
Claude and Claude Desktop: Settings, then Connectors, then Add custom connector
https://toolspoke.com/mcp
Cursor: ~/.cursor/mcp.json, or .cursor/mcp.json for one project
{ "mcpServers": { "toolspoke": { "url": "https://toolspoke.com/mcp" } } }
Codex: ~/.codex/config.toml
[mcp_servers.toolspoke] url = "https://toolspoke.com/mcp"
VS Code: .vscode/mcp.json, or the MCP: Add Server command
{ "servers": { "toolspoke": { "type": "http", "url": "https://toolspoke.com/mcp" } } }

What Kubernetes asks for

Service account token. You provide it once, when you install the connector. Toolspoke encrypts it at rest and decrypts it only for the length of a single call, and the gateway attaches it to the outbound request itself, so it is never part of the arguments an agent sends.

Service account tokenRequired: A ServiceAccount bearer token: create the account, bind it to a role, then mint a token with `kubectl create token <name> --duration=…`. Bind it to view for read-only, and grant delete on pods and update on deployments/scale only if you want the write actions to work.; eyJhbGciOi…
API server URLRequired: The cluster's publicly reachable API server endpoint, e.g. the control plane URL from your kubeconfig. Private-network and cluster-internal addresses are refused - this never reaches a socket or a local kubectl proxy.; https://k8s.example.com
Default namespaceOptional: Used whenever an action is called without an explicit namespace.; default

What Claude can do in Kubernetes

12 actions, each one declared and named by the connector rather than discovered at runtime. A workspace policy grants a person all of them, a hand-picked selection, everything on the read side, everything on the write side, or none.

Reads: 10Reads
Writes: 1Writes
Destructive: 1Destructive

Reads

Fetches data and changes nothing.

list_namespaces
List the namespaces on the cluster with their phase. Call this first when you do not know which namespace an application runs in - every other action here except list_nodes is namespace-scoped.
list_pods
List the pods in a namespace with their phase, restart counts and node. Start here when something is unhealthy: the restart count and the container statuses usually say which pod to look at, and the pod name is what get_pod, get_pod_logs and delete_pod need. Narrow with label_selector (e.g. app=checkout) or field_selector (e.g. status.phase=Running).
get_pod
Fetch one pod's full object: containers and images, resource requests and limits, volumes, conditions, and per-container state including the reason a container last terminated. This is where CrashLoopBackOff, OOMKilled and ImagePullBackOff are actually explained. Read the logs with get_pod_logs afterwards.
get_pod_logs
Read the tail of one container's log. Pass container when the pod runs more than one, or the API server refuses the request and names the choices. Set previous to true to read the log of the container that crashed rather than the one that replaced it - that is usually the log you actually want. Output is capped at roughly 20000 characters, keeping the most recent lines.
list_deployments
List the deployments in a namespace with their desired, updated, ready and available replica counts. A deployment whose ready count is below its desired count is the usual first sign of a rollout that stalled. The deployment name is what get_deployment and scale_deployment need.
get_deployment
Fetch one deployment in full: its pod template, images, replica strategy, and the conditions explaining a rollout that is not progressing. Call this before scale_deployment so you know the current replica count you are changing.
list_services
List the services in a namespace with their type, cluster IP, ports and selector. Use it to check that a service's selector actually matches the labels on the pods list_pods returned - a service selecting nothing is a common cause of "the app is up but nothing reaches it".
list_nodes
List the cluster's nodes with their conditions, capacity and allocatable resources. Use it when pods are stuck Pending - a node under MemoryPressure or DiskPressure, or one that is NotReady, explains that where the pod object does not. This is the one action here that is not namespace-scoped.
list_events
List the recent events in a namespace - scheduling failures, image pull errors, probe failures, evictions and scaling decisions, in the cluster's own words. This is the fastest explanation of why a pod will not start, and it says things no object status does. Narrow to one object with field_selector, e.g. "involvedObject.name=checkout-7c9".
describe_resource
Fetch any core-v1 namespaced object by kind and name, for the things that have no dedicated action here: configmaps, endpoints, persistentvolumeclaims, serviceaccounts, replicationcontrollers. Use it to check what a pod is actually mounting, or whether a service has any endpoints behind it. Only core-v1 kinds are reachable - deployments and pods have their own actions above.

Writes

Creates or updates something on the other side.

scale_deployment
Set a deployment's replica count by patching its scale subresource. Scaling to 0 takes the workload down and scaling up costs capacity, so read get_deployment first and put the count back when you are done. A HorizontalPodAutoscaler will overwrite this within its next sync interval.

Destructive

Deletes or permanently alters something. Worth granting on purpose.

delete_pod
Delete a pod. In practice this restarts it: anything owned by a Deployment, StatefulSet or DaemonSet is recreated immediately, which is the usual remediation for a wedged or leaking process. A pod with no controller is simply gone, and its logs go with it - read get_pod_logs first. This changes what the on-call rota sees, because the restart shows up as an event and may re-trigger a probe alert.

What it will not do

Enforced by the gateway rather than left to convention, which is why each of these can be stated flatly.

It cannot call anything else: The 12 actions above are the whole of it. A call to any other name is refused before it reaches Kubernetes rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time.
It reaches no further than your credential: Toolspoke holds no access to Kubernetes of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either.
It never hears from Kubernetes: Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Kubernetes. An agent has to ask.
It does not smooth over provider limits: Toolspoke does not retry, queue or back off around Kubernetes's own rate limits. A call that Kubernetes refuses comes back to the agent as a failed call.

Before you connect it

What can Claude do in Kubernetes?

12 named actions: 10 that only read, 1 that write and 1 that delete or permanently alter something. They include list_namespaces, list_pods and get_pod. Nothing outside that list is reachable: the connector declares each operation by name rather than proxying whatever an agent asks for.

What credentials does the Kubernetes connector need?

Service account token. The connector asks for service account token and api server url, and optionally default namespace. Values are encrypted at rest and attached to the outbound request by the gateway, so they are never part of the arguments an agent sends and never reach the audit log.

Does the Kubernetes connector work with Cursor and Codex, or only Claude?

Any client that speaks MCP, and every one of them gets the same 12 actions. There is a single address, https://toolspoke.com/mcp. Claude Code adds it with claude mcp add --transport http, Claude and Claude Desktop take it as a custom connector in settings, Cursor reads it from .cursor/mcp.json, Codex from ~/.codex/config.toml, and VS Code from .vscode/mcp.json. Each of them signs in to the gateway itself, so there is no key to paste.

What does the Kubernetes connector not do?

The 12 actions above are the whole of it. A call to any other name is refused before it reaches Kubernetes rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time. Toolspoke holds no access to Kubernetes of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either. Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Kubernetes. An agent has to ask. Toolspoke does not retry, queue or back off around Kubernetes's own rate limits. A call that Kubernetes refuses comes back to the agent as a failed call.

Can I limit which actions an agent can call?

Yes, in two places. The project switches Kubernetes's actions on and off one at a time, for everyone in the project at once, and the screen groups them by read, write and destructive so turning off everything that deletes is one click. An individual agent key can then be narrowed further, to particular toolkits in a project and to particular actions in a toolkit. Whatever it was granted, a key never reaches a project its owner cannot.

What gets recorded when an agent calls Kubernetes?

Every attempt, with the agent that made it and the person that agent belongs to, the full request payload, the response payload, the status, the duration, and the credits spent. Values whose key names a secret are masked out before the record is shown to anyone. An operation the connector marks as not retained never has its response body written at all, so the gateway keeps no second copy of what was read.

More infrastructure connectors

Browse all of them