Komodor MCP server: run Kubernetes investigations
Komodor's agentic platform exposes its agents, runs, incidents and knowledge as MCP tools. A Kubernetes question reaches Klaudia by invoking one of those agents.
Checked 3 October 2026 · from Komodor's KAOP documentation, its 16 September 2026 launch announcement and requests to the hosted endpoint
One of 91 guides to monitoring and developer tools. Each covers what an AI coding agent can get out of the tool through MCP, the protocol that lets the agent query the tool directly.
Summary
Komodor runs a first-party MCP server as part of the Komodor Agentic Operation Platform (KAOP), which launched on 16 September 2026. MCP, the Model Context Protocol, is the standard AI assistants use to call external tools.
The server exposes the platform itself: agents, runs, incidents, workflows, knowledge and memory. Komodor documents connections from Claude Code, Codex CLI and Cursor.
Kubernetes answers arrive through agents rather than raw cluster reads. Your assistant invokes an agent such as Klaudia Investigator, and Komodor runs the investigation on its side.
How Komodor works with MCP
Komodor started as a Kubernetes troubleshooting platform. Its AI site reliability engineer, Klaudia, investigates cluster incidents and proposes fixes.
KAOP widens that into a platform for running governed agents on operations work: incident response, change review, cost reduction. Komodor ships more than 50 prebuilt agents, skills and integrations with it.
MCP appears in two directions. The MCP server at /internal/mcp lets your assistant operate KAOP. The MCP Gateway at /gateway/mcp does the reverse, letting KAOP agents call MCP servers and OpenAPI-described APIs that you run.
Both directions authorize each call against the same permission as the matching REST API request. An assistant connected as you can do what you can do in the console, and nothing more.
Komodor's MCP surfaces
| Surface | Path | Direction | Use it for |
|---|---|---|---|
| MCP server | /internal/mcp | Your assistant calls KAOP | Invoking agents, reading runs, managing incidents and workflows |
| MCP Gateway | /gateway/mcp | KAOP agents call your tools | Registering your own MCP servers or OpenAPI documents as agent tools |
| Docs search | docs.komodor.com/mcp | Your assistant reads Komodor's docs | Answering setup questions from the KAOP documentation |
The paths sit on your account host. On Komodor's cloud that host is kaop.komodor.com.
Every vendor here gets the same four checks: official, maintained, distributed and usable. Komodor passes 3 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Pass | Komodor documents its own MCP server as part of the Komodor Agentic Operation Platform (KAOP). |
| Maintained | Pass | The server ships inside KAOP, which launched on 16 September 2026. KAOP's public changelog lists product updates through 2 October 2026. |
| Distributed | Pass | Hosted at /internal/mcp on each account host. On 3 October 2026, https://kaop.komodor.com/internal/mcp answered an unauthenticated request with HTTP 401 and OAuth protected-resource metadata. |
| Usable | Unknown | Komodor documents the toolsets but not the individual tool names, which a signed-in account sees. |
| Part of the work | What Komodor has here | Can an agent reach it |
|---|---|---|
| Production observability | Incident investigation, Klaudia root-cause analysis, alert intelligence | Yes. The incidents and runs toolsets, plus invoking investigator agents |
| CI & release | Change intelligence, CI/CD health, production readiness modules | Partial. Reached by invoking the module's agents, not as direct pipeline reads |
| Agent observability & evals | Runs, evidence trails, golden-scenario evaluations | Yes. The runs and goldens toolsets read KAOP's own agent runs and test suites |
| AI cost management | Kubernetes, cloud and observability cost modules; agent spend attribution | Partial. Cost work runs as agents; Komodor does not document a dedicated cost toolset |
Komodor's server is strongest for incident work, because the incidents toolset and Klaudia's investigators sit behind one connection. For raw pod or event reads, a Kubernetes connector is more direct.
What can an AI agent do with Komodor?
Klaudia answers about some clusters and not others
Klaudia Investigator reads nothing directly. Komodor's documentation says its reach is whatever your Komodor account's agent already covers.
The in-cluster investigators, Kubernetes RCA and Cluster Investigator, see only the single cluster they are deployed in.
Guard: Check which clusters the Komodor account covers before treating a missing answer as a healthy cluster.
The assistant acts in a different Komodor account than you expected
Each connection is bound to exactly one account. Komodor serves a whoami tool on every connection, whatever the scoping, because nothing else reports the account.
Guard: Have the assistant call whoami before any write, and confirm the account name it returns.
Tool descriptions crowd the context window
An unscoped connection serves every toolset. Komodor's own documentation warns that a model given the whole surface spends context on descriptions it never calls.
Guard: Add ?toolset= to the URL with only the toolsets the task needs.
How to configure Komodor MCP for agents
- 1
Pick the identity
A personal OAuth sign-in or key acts as you. A service account key acts as that account, and audit entries carry its name.
- 2
Scope the toolsets
/internal/mcp?toolset=runs,incidentsserves two toolsets.?tools=narrows further to named tools. - 3
Expect authorization by argument
A general-purpose tool may succeed for one target and fail for another, because each call maps to a specific capability.
- 4
Guardrails still apply
Rules at KAOP's tool-call gate cover the platform's own tools as well as servers behind the gateway.
Paste this into your agent’s instructions
When you answer from Komodor: - Name the Komodor account (from whoami) and the agent or run you used. - Say which clusters the answer covers. If an investigator returns nothing for a cluster, say the account may not cover it. Ask before any write to agents, workflows or incidents.
Do you need the MCP server at all?
For direct reads of pods, events and logs, connect a Kubernetes or observability server instead. Grafana reaches cluster metrics and logs through its data sources; Dynatrace exposes Kubernetes events.
Those return cluster state. Komodor's server returns Klaudia's interpretation of that state, with the evidence trail of the run that produced it.
For automation without a model in the loop, KAOP's REST API at /api/v1 covers the same capabilities. It takes an API key as a bearer token.
Use Komodor's server when you want an investigation or an incident record. Use a Kubernetes connector when you want the objects themselves.
Komodor integration setup
Komodor hosts the server, so nothing installs locally. In KAOP, open Settings → Connect coding agents for a card per client with the exact command.
Where your deployment offers OAuth, the command carries no credential and sign-in happens on first use. Otherwise the card adds a placeholder for a KAOP API key.
Claude Code
The documented shape is your account host plus /internal/mcp. Adding ?toolset= keeps the connection narrow.
claude mcp add --transport http komodor \ "https://kaop.komodor.com/internal/mcp?toolset=core,runs,incidents"
Cursor
Cursor's deep link cannot carry a header. On a deployment without OAuth, use the manual snippet from the settings card and add your API key there.
{"mcpServers":{"komodor":{
"url":"https://kaop.komodor.com/internal/mcp",
"headers":{"Authorization":"Bearer <kaop-api-key>"}}}}Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Codex CLI
KAOP's settings tab has a Codex CLI card alongside Claude Code and Cursor. Copy its command, which matches your deployment's authentication mode.
What the vendor documents
Public material on the server comes from Komodor: the KAOP documentation and the 16 September 2026 launch announcement. The announcement says workflows deploy "over 50 out-of-the-box specialist agents, skills, integrations and MCPs provided by Komodor."
Should you connect an agent to Komodor?
Yes, if your team runs Komodor's agentic platform and wants Klaudia's investigations inside a coding agent. Best for SRE and platform teams already using KAOP for incident response.
- Strongest fit
- Yes, if your team runs Komodor's agentic platform and wants Klaudia's investigations inside a coding agent.
- Main advantage
- One connection reaches Klaudia, the incident record and every agent run, under the same permissions as the console.
- Main weakness
- Cluster data arrives through agent runs, so simple reads are slower than a direct Kubernetes connector.
- Operational risk
- An assistant connected with a broad identity can create agents, change workflows and manage incidents.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface.
See agent observabilityFrequently asked questions
Does Komodor have an MCP server?
Yes. It is part of the Komodor Agentic Operation Platform, launched 16 September 2026, and served at /internal/mcp on your account host.
Can my agent ask Klaudia why a pod is failing?
Yes, by invoking an investigator agent such as Klaudia Investigator through the runs toolset. Klaudia's reach is limited to the clusters your Komodor account covers.
How does the Komodor MCP server authenticate?
With OAuth where the deployment offers it, otherwise with a KAOP API key sent as a bearer token.
Can Komodor's agents use my own MCP servers?
Yes. Register them in the MCP Gateway, which also turns an OpenAPI document into agent tools, then add them to an integration group.
