Klaudia MCP Server

Overview

The Komodor AI SRE MCP Server exposes Klaudia's cluster visibility, health analysis, cost insights, and investigation/remediation capabilities as MCP tools - so engineers can work with Klaudia directly from any MCP-compatible client (Codex, Cursor, Claude, or an internal agent platform) instead of switching to the UI or Slack. This lets teams embed Klaudia into their own developer workflows and agentic tooling while preserving the same RBAC and data boundaries as the rest of Komodor.

Note: The MCP Server is currently in beta. Contact your Komodor CSM to have it enabled for your account.

How it works

Each tool call runs under the identity and RBAC of the authenticated user - Klaudia only surfaces data and actions that user is already entitled to in Komodor.

Endpoints

Point your MCP-compatible client at the Komodor MCP Server endpoint for your region:

Authentication

You can authenticate in one of two ways. Either way, every tool call runs under your existing Komodor identity and RBAC, the same as using the Komodor UI directly.

Option 1: OAuth (interactive clients)

For clients that support a browser consent flow (e.g. Codex, Claude Desktop, claude.ai web connector):

1. When you connect the client to the Komodor MCP Server, it opens a browser consent screen.
2. Choose Allow Access.
3. Your client now holds a token scoped to your own Komodor identity, which it presents on each request.

Option 2: Komodor API key (static bearer header)

For CLI and config-file clients, authenticate with a static header instead of the OAuth flow.

• Header: Authorization: Bearer <YOUR_KOMODOR_API_KEY>
• Generate a key: Komodor UI → Settings → User Settings → API Keys
• Tool access follows that key's user RBAC. The key is account + user scoped, so a user without the Klaudia permission can use every tool except the Klaudia chat tools (ask_klaudia, get_klaudia_chat_result, respond_klaudia_chat, upload_klaudia_attachment).
• Prefer env-var interpolation over hardcoding the key. The examples below resolve the key at runtime rather than storing it in plaintext.
• Restart the editor/client after editing its config.
• EU accounts: substitute https://mcp.eu.komodor.com/mcp in the examples below.
• Claude Desktop and the claude.ai web connector cannot send a static header. Use OAuth (Option 1) for those.

Claude Code (CLI) — export the key, then add the server:

claude mcp add --transport http komodor https://mcp.komodor.com/mcp \
  --header "Authorization: Bearer $KOMODOR_API_KEY"

Codex CLI (OpenAI) — Codex reads the token from the env var at connect time, so keep it exported in the shell where you run codex:

export KOMODOR_API_KEY=<YOUR_KOMODOR_API_KEY>
codex mcp add komodor \
  --url https://mcp.komodor.com/mcp \
  --bearer-token-env-var KOMODOR_API_KEY

Cursor — ~/.cursor/mcp.json:

{
  "mcpServers": {
    "komodor": {
      "url": "https://mcp.komodor.com/mcp",
      "headers": { "Authorization": "Bearer ${env:KOMODOR_API_KEY}" }
    }
  }
}

Windsurf — ~/.codeium/windsurf/mcp_config.json (uses serverUrl; fully restart Windsurf after editing):

{
  "mcpServers": {
    "komodor": {
      "serverUrl": "https://mcp.komodor.com/mcp",
      "headers": { "Authorization": "Bearer ${env:KOMODOR_API_KEY}" }
    }
  }
}

VS Code (Copilot agent mode) — .vscode/mcp.json (prompts for the key via an inputs entry):

{
  "servers": {
    "komodor": {
      "type": "http",
      "url": "https://mcp.komodor.com/mcp",
      "headers": { "Authorization": "Bearer ${input:komodor-api-key}" }
    }
  },
  "inputs": [
    { "id": "komodor-api-key", "type": "promptString", "description": "Komodor API key", "password": true }
  ]
}

Gemini CLI (Google) — ~/.gemini/settings.json (uses httpUrl):

{
  "mcpServers": {
    "komodor": {
      "httpUrl": "https://mcp.komodor.com/mcp",
      "headers": { "Authorization": "Bearer ${KOMODOR_API_KEY}" }
    }
  }
}

Available tools

Cluster & Service Visibility

• whoami - Confirms the authenticated Komodor identity and verifies the connection.
• get_clusters - Lists all Kubernetes clusters accessible in the Komodor workspace.
• get_services_by - Searches workloads/services by cluster, namespace, kind, or health status.
• get_service_yaml - Retrieves the full manifest for a workload (Deployment, DaemonSet, StatefulSet, Rollout).

Health & Cost

• get_health_risks - Lists health risks, violations, and misconfigurations across clusters/namespaces.
• get_health_risk_data - Retrieves detailed analysis for a specific health risk by ID.
• get_cost_right_sizing_per_service - Service-level right-sizing recommendations and potential savings.
• get_cost_right_sizing_per_container - Container-level CPU/memory right-sizing recommendations.

Investigation & Remediation

• trigger_klaudia_rca - Starts an automated Klaudia root-cause analysis on a Kubernetes resource.
• get_klaudia_rca_results - Checks RCA progress and retrieves the final analysis.
• ask_klaudia - Starts or continues a Klaudia chat session for infrastructure questions, investigation, or remediation guidance.
• get_klaudia_chat_result - Polls a chat session until it completes, fails, or pauses (and flags if a session appears stalled).
• respond_klaudia_chat - Responds to a paused chat (e.g., approving/rejecting a suggested action, selecting an option).
• upload_klaudia_attachment - Uploads a file or image for Klaudia to use within a chat session.

When to use it

• Working inside a coding agent - When you're already in Codex, Cursor, or a similar tool, you can trigger a Klaudia RCA or ask a question about your cluster without leaving your editor.
• Embedding Klaudia into internal platforms - Point your own developer portal, chatbot, or internal agent at the MCP Server to give your engineers Klaudia's investigation and remediation capabilities inside tools they already use.