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.
Set it up
Section titled “Set it up”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?”
Troubleshooting
Section titled “Troubleshooting”- “Can’t reach KubeGlass”: the MCP server needs KubeGlass running at its
--url. Check thatcurl <url>/healthzanswers. - Tools don’t show up: reload the client after editing its config, and check that
kubeglassis on the client’sPATH. - Empty or “forbidden” answers: the tools have the same permissions as the KubeGlass session. Run
whoamito see who that is.