Summary

The whole loop — what broke, which pod says so, and the re-sync — happens without opening the Argo CD UI.

Diagnosis and remedy sit in one server: you can walk from application to resource tree to the failing pod's container logs, then sync with prune and a pinned revision in the next call. The filtering on managed resources is the tell that this was built against real clusters — a large application returns more than a model can hold, and kind, namespace and project narrow it before that becomes a problem.

What it is

An Argo CD API client covering the read path an operator uses during an incident and the write path that resolves it. It speaks stdio for a local client and HTTP stream for a shared deployment, against the instance named by its base URL — or several instances, when you give it a token registry.

What you get

The state of an application and the resource tree beneath it, for default and non-default application namespaces
Logs from an application's workload — Deployment, StatefulSet or Pod — down to a named container
Events at both levels: on the application, and on a single managed resource
Managed resources filtered by kind, namespace, group, version or project, which is how you keep a large application's response inside the model's limits
Live manifests for specified resource references, or for everything the application manages
The AppProject behind an application, so the permissions and restrictions applying to it are visible
Sync with dryRun, prune, a target revision and sync options, plus the resource actions Argo CD exposes for a given resource
Application lifecycle from chat: create in a chosen namespace, update, and delete with a cascade and propagation policy
The clusters registered with the instance, searchable by name or server
More than one Argo CD from one server: a JSON token registry maps a base URL to its own token, and a call can name which instance it means

Requirements

An Argo CD instance reachable at ARGOCD_BASE_URL and an API token in ARGOCD_API_TOKEN. The token's rights decide what succeeds, and applications in non-default namespaces need their namespace named or the call fails on permissions. For several instances, point ARGOCD_TOKEN_REGISTRY_PATH at a JSON file — a mounted secret, say — keyed by base URL; the default token is bound to the default instance and is never sent to another host, so an override without a registry entry fails before any request goes out. A registry path that is missing or malformed stops the server at startup rather than quietly using the wrong credential.

Setup effort

One command plus a key — docker run -e ARGOCD_BASE_URL=<argocd_url> -e ARGOCD_API_TOKEN=<argocd_token> argoprojlabs/mcp-for-argocd, then supply credentials