Argo Rollouts MCP server: there isn't one

A well-adopted MCP server exists next door for Argo CD. It does not cover Rollouts, and rollout state has to be read as a Kubernetes custom resource instead.

Last verified 1 September 2026 · from The argoproj GitHub organization, GitHub search and the official MCP registry

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Argo Rollouts MCP server, and is it usable?

Argo Rollouts replaces the Kubernetes Deployment object with one that understands canary and blue-green strategies. A canary sends part of the traffic to the new version first; blue-green runs both versions and switches over. Rollouts runs analysis against metrics, then promotes or aborts on the result.

That makes it exactly the kind of thing an agent would want to query during an incident: which step a rollout is on, whether analysis passed, and whether it was aborted. None of that is reachable over MCP.

The confusion is structural rather than careless. Argo CD and Argo Rollouts are separate controllers in the same family, and the server that exists names the family in its title.

Every one of the 90 vendors in this directory gets the same four checks. Argo Rollouts passes 0 of them.

Rollouts works in CI and release, and publishes nothing for any stage.

No tool returns the canary verdict to an agent. Rollouts runs the analysis and holds the decision, but no tool returns it, so the agent has to read the underlying metrics and form its own opinion.

What can an AI agent do with Argo Rollouts?

Argo Rollouts has no MCP server, which is why this needs a page rather than a redirect to Argo CD.

Do you need the MCP server at all?

No. Rollouts ships no connector of its own. The kubectl argo rollouts plugin is the direct route, and it is the one Rollouts documents. get rollout returns the current step, the analysis result and whether the rollout is paused or degraded, which is exactly the state an agent wants.

A Kubernetes connector reaches the same information as custom resources. Rollout, AnalysisRun and Experiment are all Kubernetes objects, so anything that can read a CRD can read the rollout's status block without Rollouts publishing anything.

For the metrics the analysis is judging, connect the provider directly. Rollouts queries Prometheus, Datadog, New Relic and others to decide a canary. An agent connected to Prometheus reads the same series the controller reads, and reaches its own view.

For the GitOps side, argoproj-labs/mcp-for-argocd is useful: it covers Argo CD applications and sync state, which is where a rollout is usually triggered from even though it cannot see the rollout itself.

Read rollout state as a Kubernetes custom resource, and judge the canary from the metrics provider the analysis uses.

Argo Rollouts MCP server setup

Nothing here installs an Argo Rollouts server, because there is none. This is the working route: read the Rollout from Kubernetes, and read the numbers its analysis used from the metrics provider.

Argo Rollouts ships a kubectl plugin, documented on its own site, and a Rollout is an ordinary custom resource. An agent that already has cluster access can reach both.

The Argo CD server is listed last because it is a different product. Teams running Rollouts usually run Argo CD too, and it is the one connector that exists nearby.

kubectl argo rollouts get rollout canary-demo -w
kubectl get rollout canary-demo -o json

claude mcp add-json "prometheus" '{"command":
  "prometheus-mcp-server",
  "args":["--mcp.tools=core",
          "--prometheus.url=http://localhost:9090"]}'

{"mcpServers":{"argocd-mcp":{
  "command":"npx",
  "args":["argocd-mcp@latest","stdio"],
  "env":{"ARGOCD_BASE_URL":"<argocd_url>",
         "ARGOCD_API_TOKEN":"<argocd_token>"}}}}

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

resources: ["rollouts","analysisruns","experiments"]
verbs:     ["get","list","watch"]

Read-only access, permissions and security

• Your kubeconfig is the whole permission model

  There is no Rollouts server to scope, so what the agent can read is decided entirely by the context and RBAC it inherits.

• Rollouts resources sit in one API group

  rollouts, analysisruns and experiments under argoproj.io are the objects worth granting, and get, list and watch are enough to answer questions.

• The Argo CD server is a separate trust boundary

  It takes its own ARGOCD_API_TOKEN, and that token's permissions in Argo CD decide what it returns, independently of your cluster role.

• A promotion decision is a write

  Reading rollout state is safe. The plugin can also promote and abort, so an agent with a shell has more than read access unless the role forbids it.

• The metrics provider carries its own exposure

  Connecting Prometheus to explain a canary gives the agent every series in that Prometheus, not only the ones the analysis used.

Troubleshooting

You connected `mcp-for-argocd` and Rollouts data is missing

That server is for Argo CD, the GitOps delivery controller. Argo Rollouts is the progressive delivery controller, and it is a different project.

Analysis runs, canary steps and experiments have no tools in it, or anywhere else.

You cannot find an Argo Rollouts MCP server

There is not one. A search of the argoproj organization returns zero MCP repositories, and a global search for repositories naming both Argo Rollouts and MCP also returns zero.

The nearest server looks well adopted, so it seems safe to assume coverage

argoproj-labs/mcp-for-argocd carries 563 stars and was pushed on 11 August 2026, which is exactly why the assumption is easy to make.

Adoption of a neighbouring server says nothing about coverage of this one.

You want to know whether a canary was promoted or rolled back

Read it from Kubernetes. The Rollout resource holds that state, so an agent with cluster access can query it directly rather than through a connector.

Argo Rollouts MCP server: Reference

What engineers report

argoproj-labs/mcp-for-argocd carries 563 stars and is actively developed, so the two reports below are filed against a server people use. The searches matter more than usual here, because a plausible-looking server exists under a similar name.

“The list_applications tool returns ALL applications with ALL fields, consuming excessive tokens even with small deployments.”

“Each process binds its own callback listener for the lifetime of the process, and the callback port defaults to 8085 for every environment.”

The argoproj GitHub organization was searched for MCP repositories, and GitHub was searched globally for repositories naming both Argo Rollouts and MCP. Both returned zero results on 24 August 2026. The official MCP registry has no Argo Rollouts entry.

Should you connect an agent to Argo Rollouts?

No. There is nothing to connect. Best for a Kubernetes connector for rollout status, plus the metrics provider the analysis reads.

Strongest fit

Teams doing progressive delivery who will read rollout state as a Kubernetes resource.

Main advantage

Rollout state is a Kubernetes custom resource, so an agent with cluster access reads it without any connector.

Main weakness

The canary verdict, which only Rollouts computes, cannot be queried by an agent.

Operational risk

The real risk is connecting the Argo CD server and assuming Rollouts is covered.

Frequently asked questions