Devtron MCP uses NitroStack to give AI clients a hosted, read-only view into applications, deployments, Helm releases, and Kubernetes diagnostics, without opening write access to the cluster.
What this enables
- An engineer can ask which applications are unhealthy, identify ownership, and read pod logs from one conversation.
- Deployment history, active configuration, and installed Helm releases are all reachable through the same investigation flow.
- The MCP server is hosted remotely through NitroCloud, so customers don't have to run another component inside their own cluster.
- Deployment, editing, and pod exec are excluded entirely — the server can investigate, not act.
110 operations, and the real question is which ones matter
Devtron's own platform already gives teams a broad control surface over Kubernetes — applications, clusters, deployment history, Helm releases, configuration, and troubleshooting. The orchestrator specification used for this project covered 110 operations across 27 domains. Converting all of them into MCP tools one-for-one would have been the straightforward implementation, and a poor interface: a platform engineer mid-incident isn't thinking about which of 110 endpoints to call. They're thinking about what's failing, who owns it, what changed, and what the logs say.
Devtron MCP was built around those four questions instead, grouping the read-side capabilities into platform scope, applications, deployment information, and diagnostics, with Helm visibility folded into the operational view. That's enough surface to move through a realistic investigation without handing the model any ability to change the environment.
An investigation that starts with one ordinary question
A platform issue rarely arrives with a pod name, namespace, and cluster ID already attached to the prompt — it starts with something like "which applications are failing right now?" list_applications answers that at the application level; in the synthetic demo, it identifies payments-worker as degraded in production, rendered through an application-list widget instead of a raw response object.
From there the conversation gets more specific on its own. Asking who owns payments-worker triggers get_application_details, which returns metadata including projectName: "checkout-team" and a team: checkout label — the problem now has an owner. The obvious next question, "show me the logs," triggers get_pod_logs, and in the demo case the log viewer surfaces java.sql.SQLException: Connection refused. That's a broad infrastructure question narrowed to a specific application and a concrete error without the engineer manually navigating several screens to get there. Inventory belongs in a list, logs belong in a log viewer, and NitroStack's Widget SDK attaches each to its matching tool response inside compatible MCP and ChatGPT interfaces — the conversation supplies direction, the widget supplies the right surface for the information.
"What changed?" is often the more useful next question
Finding an error explains what's happening now; the next useful question is usually historical.
get_deployment_history pulls the deployment timeline for the affected application and pipeline — in the demo, payments-worker shows deployment #1001, triggered an hour earlier. That opens a real investigative path: was the failure present before that deployment, and what changed in the release?
get_deployment_detail retrieves the selected deployment's information, and get_deployed_configuration returns the configuration tied to that run, including deployment-template data and ConfigMap or Secret categories. list_installed_charts adds installed Helm information — in the production fixture, releases like PostgreSQL and Redis tied to the payments environment. None of these are arbitrary additions; together they follow how an engineer actually works an incident: find the unhealthy app, identify ownership, inspect logs, review the recent deployment, inspect configuration, check dependencies. Devtron's own platform already connects these concepts in its dashboard — the MCP layer gives an AI client a controlled route into that same operational evidence.
Hosting a self-hosted product's AI layer separately
Devtron commonly runs inside a customer's own Kubernetes environment, which creates a real distribution question: how do you add an MCP integration without turning it into another component every customer has to deploy and maintain themselves?
The design separates that concern. The MCP application is hosted through NitroStack's cloud layer and exposed as a remote endpoint, while the Devtron installation stays exactly where the customer runs it. NitroCloud is built for hosting MCP servers behind persistent HTTPS endpoints, with deployment, scaling, and observability handled at the hosting layer, so a compatible AI client connects to a remote endpoint rather than requiring the server to live beside it. Devtron keeps owning Kubernetes state and operational data; the MCP server is a separate interface for requesting approved information about it. The proof of concept also includes a synthetic fixture mode (DEVTRON_USE_FIXTURES=true) so the whole experience can be demonstrated without a real Kubernetes environment, with widgets carrying a visible synthetic-data badge rather than a demo-notes disclaimer.
The most important tool call is the one that refuses
The clearest signal in the demo may be what doesn't happen. Asking the server to "deploy version 1.2.4 of payments-worker to production" returns a refusal: DevtronError: This server is read-only. Deploying and editing resources are not available. The same boundary applies to hibernating workloads, rotating pods, or a bulk deployment — those are candidates for a future workflow built around preview and explicit confirmation, not something quietly mixed into a server designed for inspection.
One capability sits outside the tool surface entirely regardless of future phases: pod exec. Devtron's broader platform supports terminal-based Kubernetes troubleshooting, but Devtron MCP doesn't translate that into a conversational tool — an open-ended execution surface inside a running workload is a materially different risk than retrieving a bounded set of logs or a deployment history, and the project treats it as out of scope rather than a feature to add later.
Where NitroStack fits
The NitroStack SDK provided the MCP framework for defining the tools and validating their inputs, the Widget SDK provided the visual layer keeping application state, logs, and deployment history readable inside the conversation, and NitroCloud provided the hosting path that turns the server into a remote, persistent endpoint rather than something bundled into each customer's cluster. Devtron remains the Kubernetes platform and system of record; the MCP server exposes a selected, read-only slice of it; NitroStack is the framework and hosting layer connecting the two.
Reusable takeaway
The interesting part of Devtron MCP isn't the tool count — it's the restraint. Starting from the questions engineers actually ask during an incident, exposing narrow tools for the evidence behind those answers, hosting the surface where clients can reach it without extra deployment burden, and drawing a permission boundary that's impossible to misread (no deploys, no edits, no pod exec) is a more durable pattern for a privileged system than exposing everything the underlying platform can technically do.
Teams building an MCP interface around Kubernetes or another privileged system can look at the NitroStack SDK and NitroCloud for defining a scoped tool surface and hosting it independently of the underlying platform's deployment footprint.