Kubently

What kubently MCP server does

The kubently MCP server exposes Kubently’s Kubernetes troubleshooting capabilities to MCP-compatible clients. Its primary interaction is the ask_kubently tool, which accepts a natural-language question such as why a pod is crashlooping and returns an agent-generated investigation. The system is intended for self-hosted, vendor-neutral use and can work with multiple registered clusters.

Questions can be analyzed across a fleet in parallel rather than being limited to the cluster configured in a local kubeconfig. Kubently’s broader analysis includes issue detection, root-cause investigation, solution recommendations, log analysis, resource inspection, and kubectl-based operations.

How it works

Kubently separates the central API from cluster access. Executors establish outbound connections to the API, which allows the design to reach clusters behind firewalls or NAT without inbound ingress, a shared kubeconfig, or distributing per-cluster credentials. The API can coordinate analysis across registered executors and maintain conversation context with Redis.

MCP access is available either through the kubently mcp command or through an HTTP endpoint. A client sends a troubleshooting request to Kubently, and the system uses its configured LLM provider and Kubernetes access to investigate the question. The project also supports the A2A protocol for communication between agents.

Setup and configuration

Install Kubently with the project’s CLI and Helm-based deployment flow, then configure an LLM provider. LLM_PROVIDER is required; supported examples are anthropic-claude, openai, and google-gemini. The corresponding provider key can be supplied through ANTHROPIC_API_KEY, OPENAI_API_KEY, or GOOGLE_API_KEY. Kubernetes 1.28 or newer and Python 3.13 or newer are listed by the project.

After installation, add the local MCP process to Claude Code with claude mcp add kubently -- kubently mcp. HTTP clients can connect to /mcp/ and send the X-API-Key header. The project’s installer can deploy the Helm chart, configure secrets, install the executor, and port-forward the API.

Tools and capabilities

The kubently MCP server is suited to:

• Asking Kubernetes troubleshooting questions in natural language.
• Investigating workloads, logs, events, and resource state.
• Diagnosing problems across multiple registered clusters.
• Returning root-cause findings and suggested solutions.
• Connecting MCP clients to Kubently through stdio or HTTP.
• Using outbound executors for clusters that are not directly reachable.

Kubently also documents Alertmanager-to-Slack diagnosis, scheduled fleet reports, recurring checks, and deployment verification. These are broader Kubently features and may require additional webhook, Slack, Helm, or scheduling configuration beyond basic MCP use.

Limitations and notes

The kubently MCP server depends on a deployed Kubently API and executor arrangement; MCP alone does not provide Kubernetes access without that backend configuration. HTTP access requires the configured API key.

The system is self-hosted, so operators must deploy and secure its components. TLS, API-key authentication, OAuth/OIDC, and cert-manager support are documented, but their exact configuration depends on the deployment. The README names Claude Code, Cursor, and Claude Desktop as MCP clients; other clients may require their own MCP configuration details.