Flagger MCP server: there isn't one
Flagger shifts a slice of traffic to a new version, watches metrics, then promotes or rolls back. That verdict is invisible to an agent.
Last verified 1 September 2026 · from The fluxcd GitHub organization 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.
Summary
Nobody publishes a Flagger MCP server. The fluxcd organization that owns it returns zero MCP repositories, and the official registry has no entry.
This is not a dormant project. Flagger carries 5,396 stars and was pushed on 1 September 2026, so the absence is a choice about scope rather than a sign of neglect.
Flagger runs the canary analysis and decides whether to promote or roll back, and an agent cannot ask it what it decided.
What is the Flagger MCP server, and is it usable?
Flagger automates progressive delivery on Kubernetes. It shifts traffic gradually, runs metric checks at each step, and promotes or rolls back based on the result.
It works through a service mesh or ingress controller, and it records everything as Kubernetes resources: a Canary object holds the configuration, the current phase and the outcome.
That last detail is what makes the missing server less painful here than it looks. The state an agent wants is already in the cluster, in a standard format, and does not need Flagger to publish anything.
Every one of the 90 vendors in this directory gets the same four checks. Flagger passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | No MCP server. A search of the fluxcd GitHub organization, which owns Flagger, for MCP repositories returns zero results on 1 September 2026. |
| Maintained | Fail | There is nothing to maintain. Flagger itself is active, pushed 1 September 2026 with 5,396 stars, and publishes no server. |
| Distributed | Fail | No package, and no Flagger entry in the official MCP registry. |
| Usable | Fail | Nothing exists to connect to. |
Flagger works in CI and release, and the fluxcd organization that owns it returns zero MCP repositories.
| Part of the work | What Flagger has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | None | Nothing for code or review |
| CI & release | Canary releases, traffic shifting, automated rollback | No. This is the product's purpose, and none of it is reachable directly from an agent |
| Production observability | Metric checks against Prometheus and others | No. Flagger queries metrics providers to judge a canary and exposes no tool of its own |
| Agent observability & evals | None | No traces or evaluations, and no server |
| AI cost management | None | No spend data, and no server |
Flagger's verdict is reachable, but as a Kubernetes resource rather than as a tool. An agent connected to the cluster can read the Canary object's phase directly, which is closer than most vendors in this guide get without a server.
What can an AI agent do with Flagger?
Flagger's state looks unreachable at first. The verdict is readable, but only as a Kubernetes resource.
There is no tool that returns a canary verdict, and the verdict is still readable.
The fluxcd organization publishes no MCP repository, so nothing exposes Flagger's analysis as a tool. Flagger itself is active, with 5,396 stars and a push on 1 September 2026.
Flagger records the canary phase, the current weight and the failure count on the Canary custom resource, so the information is in the Kubernetes API whether or not Flagger publishes a server.
Guard: Point the agent at the Canary resource rather than looking for a Flagger connector, and treat the phase field as the verdict.
Do you need the MCP server at all?
No. Flagger leaves this to the cluster. A Kubernetes connector is the direct answer, and an unusually complete one here. Flagger's Canary object carries the phase, the canary weight, the number of failed checks and the last transition time, so reading the resource gives an agent the whole state machine.
For the metrics the analysis is judging, connect the provider. Flagger queries Prometheus, Datadog and others to decide each step, so an agent connected to Prometheus can evaluate the same series Flagger is evaluating and reach an independent view.
For the tool that deploys the workload from Git in the first place, argoproj-labs/mcp-for-argocd covers Argo CD applications and sync state. Flux itself has no equivalent in the fluxcd organization.
For the mesh doing the traffic shifting, no common service mesh publishes a first-party MCP server, whichever one you run.
Read the Canary resource through Kubernetes for the verdict, and the metrics provider for the evidence behind it.
Flagger MCP server setup
Nothing here installs a Flagger server, because there is none. This is the working route: read the Canary resource from Kubernetes, and read the metrics its analysis queried.
Flagger records its own progress on the Canary object. The phase, the current weight and the failure count are all fields an agent can read without any connector.
The metrics half matters because the Canary tells you what was decided, and the metrics provider tells you why.
Read the canary from the cluster
kubectl get canary lists every canary and its phase across namespaces. describe adds the event history, which is where a rollback records its reason.
The agent inherits your kubeconfig, so no credentials appear in these commands. The cluster's own role-based access control decides what comes back.
kubectl get canary --all-namespaces kubectl describe canary <name> -n <namespace>
Read the metrics behind the decision
Flagger's analysis queries a metrics provider on an interval and promotes or rolls back on the result. Prometheus is the default in its own documentation.
The block holds no credentials, only the Prometheus URL. --mcp.tools=core registers nine querying, metadata and documentation tools and leaves the administrative group unregistered. The flag names a group, not individual tools, and the tool names are not published here.
claude mcp add-json "prometheus" '{"command":
"prometheus-mcp-server",
"args":["--mcp.tools=core",
"--prometheus.url=http://localhost:9090"]}'Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Narrowing what the agent can read
Canaries live in the flagger.app API group. A role limited to reading them keeps the agent away from the workloads Flagger is shifting traffic between.
No credentials sit in the role. It bounds the kubeconfig the agent already has.
apiGroups: ["flagger.app"] resources: ["canaries"] verbs: ["get","list","watch"]
Read-only access, permissions and security
Nothing to scope means nothing to misconfigure
With no Flagger server, there is no token to issue and no tool allowlist to get wrong. The exposure is whatever cluster access the agent already holds.
Canaries are in the
flagger.appgroupGranting
get,listandwatchoncanariesanswers the promotion question without reaching the Deployments underneath.Events carry the reason
A rollback records why on the Canary's events, so an agent that can only read the object misses the explanation unless events are readable too.
Flagger acts on the cluster
It shifts traffic and can roll back workloads. That is Flagger's own service account, not the agent's, and the two should not share one.
Prometheus is all-or-nothing
There is no per-metric scoping, so connecting it for canary analysis exposes every series that Prometheus holds.
Troubleshooting
- You cannot find a Flagger MCP server
- There is not one. A search of the
fluxcdorganization, which owns Flagger, returned zero MCP repositories on 1 September 2026. - The project looks dormant because nothing MCP exists
- It is active. Flagger carries 5,396 stars and was pushed on 1 September 2026, so the absence is a choice about scope rather than neglect.
- You want to ask whether a canary was promoted or rolled back
- Flagger runs the canary analysis and makes that decision, and no tool returns it. Read the Canary resource from Kubernetes instead.
- You are looking for a Flux server to cover it
- The search covered the whole
fluxcdorganization, not just Flagger, and returned zero MCP repositories. There is no sibling server to fall back on.
Flagger MCP server: Reference
| Item | Value |
|---|---|
| Server published | None |
| Owning organization | fluxcd |
MCP repositories in fluxcd | 0 |
| Flagger stars | 5,396 |
| Flagger last push | 1 September 2026 |
| Packages published | None |
| Official MCP registry results | None |
| What is unreachable | The canary analysis result: whether Flagger promoted or rolled back |
| Checked | 1 September 2026 |
What engineers report
Flagger's own activity is the useful context, because it separates a missing server from an abandoned project.
| What was checked | What it shows |
|---|---|
MCP repositories in fluxcd | 0 |
| Flagger stars | 5,396 |
| Flagger last push | 1 September 2026 |
| Official MCP registry results for Flagger | None |
The fluxcd GitHub organization was searched for MCP repositories on 1 September 2026 and returned zero. Flagger's own repository facts come from the GitHub API on the same date. The official MCP registry has no Flagger entry.
Should you connect an agent to Flagger?
No. There is nothing to connect. Best for a Kubernetes connector for the Canary object, plus the metrics provider Flagger queries.
- Strongest fit
- Teams running progressive delivery who will read canary state from the Kubernetes API.
- Main advantage
- None to report for MCP, though the state is unusually accessible without one.
- Main weakness
- No tool returns the canary verdict, so the agent has to know to read the resource.
- Operational risk
- Flagger's own service account shifts traffic and rolls back workloads. Sharing it with an agent would give a diagnosis write access.
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, from $10 per million spans.
See agent observabilityFrequently asked questions
Does Flagger have an MCP server?
No. The fluxcd organization that owns Flagger has zero MCP repositories and the official registry has no entry, as of 1 September 2026.
Is the project still active?
Yes. Flagger has 5,396 stars and was pushed on 1 September 2026. The missing server is a scope decision, not neglect.
How can an agent see whether a canary passed?
Read the Canary custom resource through a Kubernetes connector. It carries the phase, the current weight and the failed-check count.
Can an agent judge the canary itself?
Yes, by querying the same metrics provider Flagger uses. Connecting to Prometheus gives the agent the series the analysis is evaluating.
