Skip to the page
orbslateOpen the console

Early access

Your clusters, in your AI's hands.

Claude reads your Kubernetes clusters through an agent that runs inside your network. Nothing is opened inbound, no key leaves your machines, and every call is your role's decision.

Read how it worksOpen the console

Sign-ups are by invitation while the product is in early access.

$ slate login
$ slate connect add kube --context prod-eu --environment prod
$ slate mcp --install claude-desktop
Pair the agent, add a cluster, hand it to your AI client.

Nothing opened inbound

The agent dials out to the service. No port, no tunnel into your network, no firewall change.

No key leaves your network

Your kubeconfig stays in your own file. The service keeps names, versions and your policy, never a credential.

Every call is your role's decision

The agent decides each call with your role and your workspace's rules before it runs, masks secrets in what comes back, and keeps an audit row.

Two ways in

On your machine

slate mcp --install claude-desktop hands the agent to Claude Desktop, Claude Code or Cursor on the same machine. The answers stay on it.

From claude.ai, on the web or a phone

Add your workspace as a connector and sign in, with the agent running slate serve inside your network. Each call goes through the service to it, decided by your role at both ends; the agent still holds every key.

A console for your team

  • People and roles

    Invite a teammate with a role. Owner, Operator and Reader decide what each may do on each tier, through any app.

  • Policy and the Simulator

    Edit the roles and the rules as a draft, try any call against it in the Simulator, and publish: the service and every agent decide by the published version.

  • The audit

    Every call: who asked, the tool, the tier, how it was decided and how it went. Filter it with chips, open a row, export it as CSV or JSON.

What Claude can read

  • kube_contexts

    The Kubernetes connections this agent has: each with its flavour, version and the namespaces its credential may list.

  • kube_list

    Lists objects of one kind, with the columns kubectl get shows for it.

  • kube_get

    One object's spec and status as YAML-like JSON; a Secret's values are always masked, managed fields dropped.

  • kube_logs

    A pod's log lines, newest last, at most 500; ANSI stripped and secrets masked.

  • kube_events

    Events in a namespace, newest first, warnings marked; optionally for one object.

  • kube_status

    One screen on a workload: replicas, conditions, each pod's restarts and last termination reason, recent warnings.

  • kube_top

    CPU and memory of pods or nodes from the metrics API, or a sentence saying the API is absent.

  • kube_rollout_history

    A deployment's revisions, newest first, with their images.

  • kube_diff

    What changed in a deployment's pod template between two revisions (the current one and the one before, unless named): images, commands, environment names, resources.

  • kube_scale

    Sets a deployment's or statefulset's replicas, with the reason the audit keeps.

  • kube_rollout_restart

    Restarts a workload's pods by a rolling replacement, as kubectl rollout restart does.

  • kube_rollout_undo

    Rolls a deployment back to an earlier revision (the one before the current, unless named): kube_rollout_history lists them.

  • kube_delete_pod

    Deletes one pod, never a workload: its controller, when it has one, starts another.

  • kube_apply

    Applies one manifest to a namespace by server-side apply. A dry run first, always: it answers what would change and a digest; the real apply is a second call with dryRun false and that digest. Kinds: Deployment, StatefulSet, DaemonSet, Service, ConfigMap, Job, CronJob, Ingress, HorizontalPodAutoscaler, PodDisruptionBudget; never a Secret.

  • datadog_monitors

    Datadog monitors with their state and when it last changed; filter by state, tags or a name match.

  • datadog_metrics_query

    A metrics query over a window: each series summarised (min, max, mean, last), its points thinned to 200 in the structured data.

  • datadog_logs_search

    Log events matching a Datadog search, newest first, at most 200: time, status, service, host and message, secrets masked.

  • datadog_events

    Datadog events over a window (deploys, alerts, config changes), newest first; filter by tags.

  • datadog_incidents

    Datadog incidents with their state, severity and whether customers were affected, when the keys may read them.

  • dynatrace_problems

    Dynatrace problems with their impact, severity, root-cause entity and what they affect; open ones unless asked.

  • dynatrace_metrics_query

    A metric selector over a window, optionally for some entities: each series summarised (min, max, mean, last), its points thinned to 200 in the structured data.

  • dynatrace_logs_search

    Log records matching a Dynatrace log query, newest first, at most 200: time, status, source and content, secrets masked.

  • dynatrace_entities

    Dynatrace entities of one type (hosts, services, process groups, …) with whether an open problem affects each; filter by a part of the name.

  • harness_pipelines

    The project's Harness pipelines: each with its stages, the environments it deploys to and how its last run ended.

  • harness_executions

    Recent runs of the project's pipelines, newest first, or one pipeline's: status, how and by whom each started, its environments, and why a failed one failed.

  • harness_trigger

    Runs a Harness pipeline, with the reason the audit keeps. Its tier is that of every environment the run deploys to, read from the pipeline itself; runtime inputs go in `inputs`, as the YAML of Harness's Run dialog.

  • rancher_clusters

    The clusters Rancher manages: each with its state, distribution, version, nodes, what is requested of its capacity, what is wrong with it, and the kube connection that reaches it.

  • rancher_projects

    Rancher's projects, the groups of namespaces its access is granted on: each with its cluster, state and namespaces; all clusters' unless one is named.

  • rancher_nodes

    The nodes of Rancher's clusters, or one cluster's: roles, readiness, kubelet version, OS, address and what is requested of each, the troubled first.

  • orbgem_search_notes

    Searches the customer's Orbgem notes by keyword (and filters such as type:runbook, tag:oncall, since:7d): each match's title, path, type, when it changed and a snippet.

  • orbgem_read_note

    Reads one Orbgem note by its title, alias or path: its text, tags and links. A long note answers in parts, saying which line continues it.

  • orbgem_recent_notes

    Lists the Orbgem notes changed most recently, newest first.

  • orbgem_daily_note

    Reads the Orbgem daily note of one day (today unless a date is given): what was captured that day.

  • orbgem_open_tasks

    Lists the unchecked checklist items across the Orbgem notes, high priority first, each with its note.

  • orbgem_log_entry

    Adds an entry to today's Orbgem daily note, the person's timeline: a finding or a result in a line or a few, with [[Title]] links to the notes it concerns.

Install and pairHow it keeps your keys