Skip to content

MCP server

kubeglass mcp is a Model Context Protocol server. An AI client starts it as a subprocess and talks to it over stdio; it answers by calling the API of a running KubeGlass. Its 41 tools only read. None of them changes anything in a cluster.

The tools act as whoever the KubeGlass session belongs to, so they see exactly what that person sees in the UI.

Start KubeGlass first (kubeglass, or use a shared deployment). Then add it to your client.

VS Code, in .vscode/mcp.json:

{
"servers": {
"kubeglass": { "type": "stdio", "command": "kubeglass", "args": ["mcp"] }
}
}

Claude Desktop, Cursor and other clients use the same command under mcpServers:

{
"mcpServers": {
"kubeglass": { "command": "kubeglass", "args": ["mcp"] }
}
}

kubeglass mcp finds a KubeGlass running on the same computer by itself, whatever port it took, and otherwise tries http://localhost:8090. With several running, each with its own KUBEGLASS_DATA_DIR, give the MCP server the same KUBEGLASS_DATA_DIR to reach that one. Without it, it reaches the one with the default data directory, or else the one that started first. For a KubeGlass elsewhere, add "--url", "https://kubeglass.example.com" to args (or set KUBEGLASS_URL). For a deployment in oidc mode, pass a JWT from the identity provider with --token or KUBEGLASS_TOKEN; in token mode, a Kubernetes token.

Area Tools
Where to start list_problems, cluster_health, cluster_info, diagnose_workload, resource_tree, health_scan
Events and logs list_events, get_pod_logs (with previous=true for a crashed container)
Resources list_resources, get_resource, list_custom_resources, list_api_resources, list_namespaces, search, resource_dependencies
Nodes and usage node_allocation, top_nodes, top_pods, rightsizing, query_prometheus
Releases and delivery list_helm_releases, get_helm_release, get_helm_values, get_helm_history, list_gitops_apps, get_gitops_app_tree, list_rollouts
Access and security whoami, can_i, who_can, network_policy_coverage, list_images, list_certificates, policy_violations, upgrade_readiness
Alerts and history firing_alerts, timeline, list_changes
Other clusters list_clusters, fleet_health, search_all_clusters

list_resources and list_custom_resources give the type’s API group and version, and each object’s name, namespace and status (state, ready count, restarts, problem and the cluster’s message), and get_resource reads one in full: give it the namespace of a namespaced object and none for a cluster-scoped one, such as a node, and the group the list gave. Without a group, get_resource reads the built-in type of that name, such as networking.k8s.io network policies where Calico serves networkpolicies too. get_resource hides Secret values, and get_helm_release the values of the Secrets in a release’s manifest; tools send KubeGlass only the arguments they declare, so the assistant can’t ask for the values; a manifest over 512 KiB gives way to the list of its objects. get_helm_values returns a release’s values as they were given, and they can hold passwords. A tool whose answer is larger than 512 KiB sends none of it, and says so and which arguments ask for less, such as namespace and labelSelector, or for list_api_resources a part of a group or kind name. resource_tree takes an optional group for a custom resource whose plural a built-in kind also has, such as a Knative Service (serving.knative.dev). Each tool’s description tells the client what it is for, so you can simply ask:

  • “Why is the checkout deployment failing?”
  • “Which pods restarted in the last hour?”
  • “Who can delete pods in production?”
  • “Which certificates expire this month?”
  • “What blocks an upgrade to the next Kubernetes version?”
  • “Can’t reach KubeGlass”: the MCP server needs KubeGlass running at its --url. Check that curl <url>/healthz answers.
  • Tools don’t show up: reload the client after editing its config, and check that kubeglass is on the client’s PATH.
  • Empty or “forbidden” answers: the tools have the same permissions as the KubeGlass session. Run whoami to see who that is.