argocd-mcp: An MCP Server That Puts Argo CD Behind a Natural Language Interface
An implementation of Model Context Protocol (MCP) server for Argo CD.
At a glance
- What is it?
- The argoproj-labs MCP server for Argo CD exposes clusters, projects, applications and resource actions as MCP tools over stdio or HTTP stream transport. It is a thin translation layer, and the interesting questions are about credentials, blast radius and what happens when the model picks the wrong tool.
- Who is it for?
- Adopt argocd-mcp if you already run Argo CD and want an MCP client to read application state, resource trees, managed resources and workload logs without leaving the editor, and if you can issue a scoped Argo CD API token for that purpose. Do not adopt it if your Argo CD instance is reachable from anywhere untrusted and you intend to run the HTTP stream transport, because the README's own Network Exposure section is the part you must read before the listener is started.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 35 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between an Argo CD dashboard and an assistant that can only read text
Argo CD already has a CLI, an API and a web UI. What it does not have is a way for an AI assistant sitting inside an editor to ask questions about a deployment and get structured answers back. That is the specific gap argocd-mcp fills. It is a Model Context Protocol server, written in TypeScript and published to npm as argocd-mcp, that translates MCP tool calls into Argo CD API calls.
The audience is narrow and identifiable: engineers who already run Argo CD, already use an MCP-capable client such as Cursor, VS Code or Claude Desktop, and want to ask things like which applications are out of sync, what the resource tree looks like for a specific app, or what the logs say for a workload, without switching windows. The README frames it as enabling AI assistants to interact with Argo CD applications through natural language. That framing is accurate but undersells the constraint: the server does not add intelligence, it adds an interface. Every answer the assistant gives is bounded by the tools the server exposes and the permissions of the Argo CD token it was handed.
Fifteen tools, one Argo CD API token, and a deliberately narrow credential path
The architecture is a proxy. An MCP client launches the server, the server authenticates to Argo CD with a base URL plus an API token, and each tool call becomes an Argo CD API request. The README lists fifteen tools grouped into four areas. Cluster and project visibility is thin: list_clusters and get_appproject. Application management is where most of the surface sits: list_applications, get_application, create_application, update_application, delete_application and sync_application. Resource inspection covers get_application_resource_tree, get_application_managed_resources, get_application_workload_logs, get_resource_events, get_resource_actions and run_resource_action.
The credential handling is the most deliberate design decision in the project, and the README states it plainly: the API token is a secret and is only ever read from the transport layer, never from a tool-call argument. It arrives either as the x-argocd-api-token HTTP header (HTTP transport only) or as the ARGOCD_API_TOKEN environment variable across all transports. The token is outbound only. It authenticates the server to Argo CD and never authorizes an inbound caller.
That separation matters because the alternative would be far worse. If the token could be passed as a tool argument, a model could be induced to supply one, and the credential would flow through the conversation transcript. Keeping it in the transport layer means the model never sees it and cannot leak it through a prompt. The README also refers to this as the default token, which implies a future or optional non-default path; the supplied material does not describe what that would be, so treat the default as the only documented behaviour.
Two transports, and only one of them has a credential header
The server supports stdio and HTTP stream transport. The distinction is not cosmetic. Under stdio, the MCP client spawns the process locally and the token arrives through ARGOCD_API_TOKEN. Under HTTP stream, the server listens and the token can arrive per request through the x-argocd-api-token header, which means the listener is reachable by something other than the process that spawned it.
The README has a Network Exposure section referenced from the credential discussion, and it is the section that governs who may reach that listener. The supplied material does not reproduce its contents, so the honest position is that the exposure model for HTTP stream transport is documented in the repository and must be read there before the listener is started. What can be said from the material is that the token being outbound-only is the mechanism that keeps an inbound caller from inheriting Argo CD permissions. Whether that is sufficient depends on details the README places in that section.
For a single developer on a laptop, stdio is the simpler and safer default, and it is what every configuration example in the README uses. All three client examples (Cursor, VS Code, Claude Desktop) pass the stdio argument to npx.
Getting it running: npx, a JSON block, and two environment variables
Prerequisites are Node.js v18 or higher, an Argo CD instance with API access, and an Argo CD API token. The README points to the Argo CD API documentation for how to obtain the token. pnpm is listed as a prerequisite for development, not for use.
The Cursor configuration goes in .cursor/mcp.json in your project:
{ "mcpServers": { "argocd-mcp": { "command": "npx", "args": ["argocd-mcp@latest", "stdio"], "env": { "ARGOCD_BASE_URL": "<argocd_url>", "ARGOCD_API_TOKEN": "<argocd_token>" } } } }
VS Code uses .vscode/mcp.json with a slightly different shape: the top-level key is servers rather than mcpServers, and the entry carries an explicit "type": "stdio" alongside command, args and env. Claude Desktop uses claude_desktop_config.json, which matches the Cursor shape with mcpServers. The README also provides one-click install badges for VS Code and VS Code Insiders that encode the same command, args and env into a vscode:mcp/install URL.
The self-signed certificate case is where the setup gets uncomfortable. If your Argo CD instance uses a self-signed certificate or one from a private CA not in the system trust store, the README suggests adding NODE_TLS_REJECT_UNAUTHORIZED set to 0 to the configuration. The README carries its own warning that this reduces security and should be used only in development environments or when you understand the implications. That warning is correct, and the setting is broader than it looks: it disables TLS certificate validation for the entire Node.js process, not just for the connection to Argo CD. The cleaner fix, trusting the CA at the system level, is not described in the material.
Where this goes wrong: mutation tools, token scope and the trust placed in a model's tool selection
The read-only tools are the easy case. Listing clusters, reading an application, fetching a resource tree or pulling workload logs are operations where a wrong answer is annoying but not destructive. The mutation tools are a different matter. create_application, update_application, delete_application, sync_application and run_resource_action all change state in a live cluster.
What the README does not contain is any described confirmation step, dry-run mode, or per-tool enablement switch. The material lists the tools and their names; it does not describe a guardrail between a model deciding to call delete_application and the Argo CD API receiving that call. If such a mechanism exists, it is not in the supplied documentation. That absence is the single largest thing to verify before pointing this at anything beyond a scratch cluster.
The practical containment is Argo CD's own RBAC. The token the server carries determines what any tool call can actually do, so a token scoped to a read-only role turns the mutation tools into calls that fail rather than calls that succeed. The README does not prescribe a role or a token scope, but the credential design points in that direction: the token is the boundary. A second failure mode is subtler. Tool selection is the model's job, and list_applications, get_application and get_application_managed_resources have overlapping-sounding names. A model that picks the wrong one gets a plausible but incomplete answer rather than an error, which is harder to notice than a failed call.
argocd-mcp versus driving the Argo CD CLI directly
The obvious alternative is the Argo CD CLI, or the Argo CD API behind a small script. The difference is not capability, since the MCP server is calling the same API underneath. The difference is who chooses the next call.
With the CLI, a human composes argocd app list, argocd app get, argocd app logs and argocd app sync as separate deliberate steps. The command is visible before it runs, and the output is whatever the CLI prints. With argocd-mcp, the model chooses among the fifteen exposed tools based on the conversation, and the human sees the result rather than the request. That trade is the whole product. It buys shorter feedback loops for read-heavy investigation and it costs you the review step on writes.
A second alternative worth naming is doing nothing. If your Argo CD usage is a handful of applications that a human syncs deliberately, adding an MCP server adds a credential, a process and a set of mutation tools with no confirmation step, in exchange for a convenience you may not need. The server earns its place when the read side dominates: many applications, frequent questions about drift, resource trees and logs, and a client where the assistant is already open.
Version cadence, licence and what to check before the first sync
Releases move fast. The recent tags are v0.7.0, v0.8.0 and v0.9.0, with v0.9.0 dated the same day as the last push to main. Pre-1.0 version numbers combined with that cadence mean tool names, configuration keys and transport behaviour should be treated as movable. The README's examples pin argocd-mcp@latest, which follows the newest release automatically. For a shared or team configuration, pinning an explicit version is the safer choice, and the material gives no compatibility matrix telling you which client versions work with which server versions.
The project is licensed Apache-2.0, a permissive licence that permits commercial and internal use and includes an explicit patent grant. That is a description of the licence text, not legal advice; if you redistribute the server or bundle it into a product, read the licence and your own policy. The repository is under the argoproj-labs organization rather than argoproj itself, which is worth noting when judging how tightly it tracks upstream Argo CD releases. The npm package is published as argocd-mcp.
Maintenance cost is mostly credential rotation and version drift. The token is a long-lived Argo CD API token sitting in a client config file, in some cases committed as .cursor/mcp.json or .vscode/mcp.json inside a project directory. Those paths are easy to commit by accident. Check your ignore rules before you write the token into either file, and prefer an environment variable reference over a literal value where your client supports it. The one thing to confirm first is the token's Argo CD role: if it can delete applications, so can any tool call the model decides to make.
Editorial conclusion
Adopt argocd-mcp if you already run Argo CD and want an MCP client to read application state, resource trees, managed resources and workload logs without leaving the editor, and if you can issue a scoped Argo CD API token for that purpose. Do not adopt it if your Argo CD instance is reachable from anywhere untrusted and you intend to run the HTTP stream transport, because the README's own Network Exposure section is the part you must read before the listener is started. Before wiring it into a shared client config, verify three things: which Argo CD RBAC role the token maps to, whether create_application, delete_application, sync_application and run_resource_action are acceptable to expose to a model in that project, and whether your certificate chain is trusted, since the documented workaround for self-signed certificates is NODE_TLS_REJECT_UNAUTHORIZED set to 0, which disables TLS validation process-wide.
Community notes