MCP for Argo CD

The server acts with a single Argo CD API token taken from the ARGOCD_API_TOKEN environment variable, and every tool, read or write, uses that same token. The server does not narrow it in any way: there is no separate read credential, no per-tool scoping and no authorization check of its own, so what the agent can do is whatever the operator's token can do in Argo CD. One good design choice is that the token is bound to the configured Argo CD host and is never sent to a different host the model names. Write tools are on by default, and the README does not steer users toward a read-only or project-scoped Argo CD account. In the HTTP transport (not the scored mode) the server also accepts the caller's token in a header and forwards it to Argo CD.

The server has no approval step of its own and relies on the MCP host. It gives the host little to work with: no tool carries read-only or destructive annotations, so a host cannot tell list_applications from delete_application by metadata. Only sync_application offers a dry-run option, and the model chooses whether to use it. The strongest control is an opt-in read-only mode (MCP_READ_ONLY=true) that removes all five mutating tools; without it, deletes with cascade, prunes and resource actions run immediately when called.

Tools are narrow and named for Argo CD operations rather than a generic HTTP client, and each has a typed schema. But almost nothing is validated beyond types: names in request paths are not strictly validated. Repository URLs, resource action names and sync options are passed through unchecked. All write tools are on by default; one environment variable removes them as a group.

The server never runs a shell, eval, or subprocess on its own host. It can, however, cause model-chosen code to run elsewhere: create_application accepts any repository URL and destination, and sync_application then has Argo CD apply whatever manifests that repository contains, which can start any container in a managed cluster. Nothing in the server isolates or constrains this; only Argo CD's own project rules, configured outside this repo, stand in the way, and the write tools are on by default.

Tool results include content that other people control: application logs, Kubernetes events, resource manifests and Application specs. The server returns them as one plain JSON text blob with no marking of what is untrusted and no separation between data and metadata. The only mode that would drop a dangerous capability, read-only, is off by default. A prompt-injected agent that reads a crafted log line can therefore delete or re-sync applications, deploy an attacker's repository to a cluster, and send data out through a repository URL Argo CD will fetch, all in the same session.

The server keeps no memory, conversation store, or retrieval index. However, at startup it calls dotenv, which loads a .env file from whatever directory the server is launched in. MCP hosts commonly start stdio servers inside the user's project, so a .env committed to a cloned repository can set variables the operator left unset, such as the Argo CD base URL, the token-registry path, or NODE_TLS_REJECT_UNAUTHORIZED=0 to turn off certificate checks. This happens silently, with no trust prompt, and persists for every session started in that directory.

The server loads no third-party code at runtime: no plugins, no dynamic imports, no subprocesses and no package installs. Its dependencies are fixed at build time. The README's 'npx argocd-mcp@latest' install line is how users fetch this server itself and is general supply-chain hygiene, not an extension mechanism.

The Argo CD token is read from an environment variable and is deliberately kept out of tool arguments, so it never passes through the model, and it is bound to the configured Argo CD host so the model cannot redirect it elsewhere. The server does not log requests, tokens or tool results, and has no telemetry. But nothing is redacted from tool output: logs and manifests returned to the model are passed through as-is. The token itself is a long-lived Argo CD credential, and the repository's own sample Cursor config ships with TLS verification disabled.

The server keeps no record of what it did. Its logger writes only startup and listener messages; tool calls, their arguments, and their results are never logged. After an incident the only trace would be whatever the MCP host or Argo CD's own audit events recorded.

Log tools always ask Argo CD for at most the last 100 lines and never follow the stream, which bounds one kind of output. Everything else is unbounded: listing applications fetches every application before applying the caller's optional limit, get_resources with no refs fetches every resource in the tree in parallel, and no HTTP request has a timeout or cancellation. There are no rate limits on the write tools.