The Argo CD MCP Server enables AI assistants to interact with Argo CD applications using natural language, providing complete API integration through stdio and SSE transport protocols. You can:
Application Operations: List, filter, get, create, update, delete, and sync applications
Resource Management: Retrieve resource trees, managed resources, workload logs, and events for applications
Resource Actions: Fetch available actions and execute them on resources managed by applications
Integration: Works seamlessly with Visual Studio Code, Cursor, and other MCP clients
Provides comprehensive access to Argo CD resources and operations, allowing management of Argo CD applications through natural language. Enables listing, creating, updating, deleting, and syncing applications, as well as managing application resources, viewing resource trees, logs, events, and executing resource actions.
Enables interaction with Kubernetes resources managed by Argo CD, including viewing managed resources, workload logs, resource events, and executing resource actions on Kubernetes objects deployed through Argo CD.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@argocd-mcp list all applications in production namespace"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An implementation of Model Context Protocol (MCP) server for Argo CD, enabling AI assistants to interact with your Argo CD applications through natural language. This server allows for seamless integration with Visual Studio Code and other MCP clients through stdio and HTTP stream transport protocols.
Transport Protocols: Supports both stdio and HTTP stream transport modes for flexible integration with different clients
Complete Argo CD API Integration: Provides comprehensive access to Argo CD resources and operations
AI Assistant Ready: Pre-configured tools for AI assistants to interact with Argo CD in natural language
Related MCP server: dbt-mcp
The server provides the following ArgoCD management tools:
list_clusters: List all clusters registered with ArgoCD
get_appproject: Get detailed information about a specific AppProject (project)
list_applications: List and filter all applications
get_application: Get detailed information about a specific application
create_application: Create a new application
update_application: Update an existing application
delete_application: Delete an application
sync_application: Trigger a sync operation on an application
get_application_resource_tree: Get the resource tree for a specific application
get_application_managed_resources: Get managed resources for a specific application
get_application_workload_logs: Get logs for application workloads (Pods, Deployments, etc.)
get_resource_events: Get events for resources managed by an application
get_resource_actions: Get available actions for resources
run_resource_action: Run an action on a resource
Node.js (v18 or higher recommended)
pnpm package manager (for development)
Argo CD instance with API access
Argo CD API token (see the docs for instructions)
Follow the Cursor documentation for MCP support, and create a .cursor/mcp.json file in your project:
{
"mcpServers": {
"argocd-mcp": {
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Start a conversation with Agent mode to use the MCP.
Follow the Use MCP servers in VS Code documentation, and create a .vscode/mcp.json file in your project:
{
"servers": {
"argocd-mcp-stdio": {
"type": "stdio",
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Start a conversation with an AI assistant in VS Code that supports MCP.
Follow the MCP in Claude Desktop documentation, and create a claude_desktop_config.json configuration file:
{
"mcpServers": {
"argocd-mcp": {
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Configure Claude Desktop to use this configuration file in settings.
If your Argo CD instance uses self-signed certificates or certificates from a private Certificate Authority (CA), you may need to add the following environment variable to your configuration:
"NODE_TLS_REJECT_UNAUTHORIZED": "0"This disables TLS certificate validation for Node.js when connecting to Argo CD instances using self-signed certificates or certificates from private CAs that aren't trusted by your system's certificate store.
Warning: Disabling SSL verification reduces security. Use this setting only in development environments or when you understand the security implications.
The server connects to ArgoCD using a base URL and an API token.
The ArgoCD API token is a secret and is only ever read from the transport layer, never from a tool-call argument:
HTTP headers (HTTP transport only): x-argocd-api-token.
Environment variables: ARGOCD_API_TOKEN (all transports).
This token is outbound only: it authenticates this server to ArgoCD and never authorizes an inbound caller. See Network Exposure for who may reach the listener.
This is the default token. It is mandatory unless a token registry is configured: on the HTTP transport, a connection that supplies no token (neither header nor env var) is rejected with 400 Bad Request, but when a registry is configured a tokenless connection is allowed because each call resolves its own registry token. Keeping the token out of tool arguments ensures it never enters prompts, model context, or tool-call logs.
The base URL may be supplied at the session level (resolved once when the server starts or when an HTTP client connects):
HTTP headers (HTTP transport only): x-argocd-base-url.
Environment variables: ARGOCD_BASE_URL (all transports).
In addition, every tool accepts an optional argocdBaseUrl argument:
If a session default base URL exists, argocdBaseUrl is optional and overrides the default for that single call.
If no session default base URL is configured (header and env var both absent), argocdBaseUrl is required; a call without it returns an error.
To target multiple ArgoCD instances, each with its own token, configure a token registry. Because the tokens are secrets, the registry is read from a JSON file, not an environment variable — point ARGOCD_TOKEN_REGISTRY_PATH at the file (e.g. a mounted Kubernetes secret). This keeps the tokens out of the process environment, crash dumps, and child-process inheritance.
ARGOCD_TOKEN_REGISTRY_PATH=/app/argocd-mcp/token-registry.jsonThe file contains a JSON array mapping a base URL to the token that should be used for it:
[
{ "baseUrl": "https://argo-a.example.com", "token": "<token-a>" },
{ "baseUrl": "https://argo-b.example.com", "token": "<token-b>" }
]Secure the file. Restrict it to the server's user (e.g.
chmod 400) and prefer a secret-management mechanism (Kubernetes secret volume, Vault agent, etc.) over a plaintext file on disk.
Local development. The
make run/make devtargets run without a registry by default; passARGOCD_TOKEN_REGISTRY_PATH=/path/to/tokens.jsonto use one. Do not place the file underdist/—tsupruns withclean: trueand wipes that directory on every build. See Running locally.
With a registry configured, a caller targets an instance by passing only the (non-secret) argocdBaseUrl argument; the server pairs it with the registered token. The token never appears in the tool-call payload.
The server resolves calls using one of two distinct tokens. Keeping them straight is what makes the security model work:
Default token | Registry token | |
Source |
| A |
Scope | The default base URL only ( | The specific base URL its entry is keyed to |
Used for | A call that targets the default base URL | A call that targets any base URL present in the registry (including the default, as a fallback) |
Never used for | Any base URL other than the default — it is never sent to a different host | Any base URL not registered |
The cardinal rule: the default token is bound to the default base URL; every other host's token must come from the registry. A registry token is bound to exactly the host it is registered under.
For a given call, the resolved base URL is the argocdBaseUrl argument if supplied, otherwise the session default. The token is then chosen by:
Call targets the default base URL → use the default token. If no default token was supplied (a tokenless session), fall back to the registry token for that base URL, if one exists.
Call targets any other base URL → use the registry token for that base URL only. The default token is never used here — it is not sent to a host other than the default one.
If neither applies (no token can be resolved for the requested base URL), the call returns a "Missing required ArgoCD API token" error and no request is made to that host.
Why the default token is bound to the default base URL. The
argocdBaseUrlargument comes from the tool call, so a caller (or a prompt-injected model) could point it at an arbitrary host. If the default token were paired with any supplied base URL, that token would be sent — as anAuthorization: Bearerheader — to the attacker's host. Restricting the default token to the default base URL, and requiring an explicit registry entry for every other host, prevents this token exfiltration. To target additional instances you must register their tokens (and thus their hostnames) up front.
Base URLs are normalized for lookup (lowercased host, trailing slashes ignored), so minor formatting differences still match. When a registry is configured, the HTTP transport no longer requires x-argocd-api-token at connection time — a tokenless connection is allowed because the per-call base URL resolves its own token. If ARGOCD_TOKEN_REGISTRY_PATH is set but the file is missing, unreadable, or malformed, the server fails closed: it throws at startup rather than silently falling back to its default credential, so a misconfigured registry can never cause calls to be routed with the wrong token.
For example, a tools/call request overriding only the base URL:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "list_applications",
"arguments": {
"argocdBaseUrl": "https://argocd.other-cluster.example.com"
}
}
}Overriding the base URL to a different instance requires a registry token. The default token (
x-argocd-api-token/ARGOCD_API_TOKEN) is bound to the default base URL only and is never sent to a different host. OverridingargocdBaseUrlto point at the default instance (same host, formatting aside) reuses the default token; pointing it at any other instance requires a registry token for that instance, otherwise the call fails with "Missing required ArgoCD API token" and no request is sent. This is intentional — see why the default token is bound to the default base URL above.
The http and sse transports open a network listener that reaches every ArgoCD tool, including create_application, delete_application, sync_application, and run_resource_action. By default it binds loopback only.
ARGOCD_API_TOKEN does not protect it. That token authenticates this server to ArgoCD. It says nothing about who the caller is. Inbound access is controlled by the settings below.
Setting | Flag | Env var | Default | What it does |
Bind address |
|
|
| Which address the listener accepts connections on. |
Inbound token | — |
| unset | When set, every request must carry |
Allowed |
| — | loopback names | Extra hostname accepted in a request's |
Allowed |
| — | loopback origins | Extra browser origin accepted in a request's |
External auth |
| — |
| Allows a non-loopback bind with no token, when something in front already authenticates callers. |
Port |
| — |
| Which port to listen on. |
--bind-addressdecides who may connect.--allowed-host-headeronly checks what an already-connected client claims. They are not a pair, and the second is not a firewall.
Flags with no env var are passed as arguments, in a container too: docker run <image> http --allow-unauthenticated.
Behaviour:
Widening the bind requires MCP_AUTH_TOKEN or --allow-unauthenticated. Otherwise the server logs why and exits non-zero instead of starting exposed.
Origin is always checked, on scheme, host, and port. This is what stops a malicious web page, including one using DNS rebinding.
Host is checked on a loopback bind, or on any bind with at least one --allowed-host-header. Otherwise the hostname clients legitimately use is unknown, so the check is skipped and a warning is logged.
GET /healthz is exempt, so a kubelet probe still succeeds. It returns liveness only.
Unusable configuration fails at startup with the reason, rather than being ignored.
Read-only mode is independent of all of this and caps what any caller can do.
Exposing the listener deliberately:
export MCP_AUTH_TOKEN=<inbound_token>
node dist/index.js http --bind-address 0.0.0.0 --allowed-host-header mcp.internal.example.comThe container image keeps the same loopback default, so it needs no extra configuration when the caller shares its network namespace, such as a sidecar in the same Kubernetes pod:
docker run -e ARGOCD_BASE_URL=<argocd_url> -e ARGOCD_API_TOKEN=<argocd_token> \
argoprojlabs/mcp-for-argocdTo publish a port, widen the bind and set an inbound credential:
docker run -p 3000:3000 \
-e ARGOCD_BASE_URL=<argocd_url> -e ARGOCD_API_TOKEN=<argocd_token> \
-e MCP_BIND_ADDRESS=0.0.0.0 -e MCP_AUTH_TOKEN=<inbound_token> \
argoprojlabs/mcp-for-argocdWhen the bind is widened and a proxy or mesh already authenticates callers, use --allow-unauthenticated instead of MCP_AUTH_TOKEN.
See Operator notes for the deployment caveats.
If you want to run the MCP Server in a ReadOnly mode to avoid resource or application modification, you should set the environment variable:
"MCP_READ_ONLY": "true"This will disable the following tools:
create_application
update_application
delete_application
sync_application
run_resource_action
By default, all the tools will be available.
By default, the HTTP transport assigns a session ID to each client connection and keeps an in-memory map of active sessions. This works well for single-instance deployments but causes 400 errors when multiple replicas are running without sticky sessions, because a request routed to a different pod will not find the session that was created on the original pod.
To run without session affinity requirements, start the server with the --stateless flag:
node dist/index.js http --statelessOr with Docker:
docker run -p 3000:3000 \
-e ARGOCD_BASE_URL=<argocd_url> -e ARGOCD_API_TOKEN=<argocd_token> \
-e MCP_BIND_ADDRESS=0.0.0.0 -e MCP_AUTH_TOKEN=<inbound_token> \
argoprojlabs/mcp-for-argocd http --statelessThe image has an ENTRYPOINT, so overriding the command replaces only the arguments. Publishing a port is what makes the wider bind and the inbound token necessary here; see Network Exposure.
In stateless mode:
No Mcp-Session-Id is returned or required — any replica can handle any request
ArgoCD credentials must be supplied on every request via environment variables or x-argocd-base-url / x-argocd-api-token headers (the base URL may also be overridden per call via the argocdBaseUrl tool argument; the API token is always header/env only)
GET /mcp and DELETE /mcp return 405 Method Not Allowed (session-level SSE and termination are not supported)
This mode is recommended for Kubernetes deployments with Horizontal Pod Autoscaling (HPA) where network-level sticky sessions are not available.
Clone the repository:
git clone https://github.com/argoproj-labs/mcp-for-argocd.git
cd mcp-for-argocdInstall project dependencies:
pnpm installStart the development server with hot reloading enabled:
pnpm run devOnce the server is running, you can utilize the MCP server within Visual Studio Code or other MCP client.
The Makefile provides targets for running the server over the HTTP transport:
make run # build, then run the HTTP server (production-style)
make dev # run from source with hot reloading (tsx watch)By default neither target sets any credentials — the server starts with no default base URL or token, so callers must supply them per request (x-argocd-base-url / x-argocd-api-token headers, or the argocdBaseUrl tool argument once a registry is configured). Override the port the same way:
make run PORT=4000To configure credentials, export the relevant environment variable on the command line. There are three (all optional):
Variable | Purpose |
| Default ArgoCD instance URL used when a call doesn't override it. |
| Static API token for the default base URL. |
| Path to a JSON token registry mapping base URLs to tokens (for targeting multiple instances). |
These are all outbound credentials. For who may reach the listener, see Network Exposure.
# Single instance with a static base URL + token:
make run ARGOCD_BASE_URL=https://argo.example.com ARGOCD_API_TOKEN=<token>
# Multiple instances via a token registry:
make run ARGOCD_TOKEN_REGISTRY_PATH=/path/to/tokens.json
# Both — a default instance plus extra instances resolved from the registry:
make dev ARGOCD_BASE_URL=https://argo.example.com ARGOCD_API_TOKEN=<token> \
ARGOCD_TOKEN_REGISTRY_PATH=/path/to/tokens.jsonSee Token resolution for how the default token and registry interact. If ARGOCD_TOKEN_REGISTRY_PATH is set but the file is missing, unreadable, or malformed, the server fails closed at startup.
Keep tokens out of your shell history. Passing
ARGOCD_API_TOKEN=<token>directly on themakecommand line records the secret in your shell history and exposes it in the process list. Prefer exporting it in the shell first so it never appears in themakeinvocation:export ARGOCD_API_TOKEN=<token> make run ARGOCD_BASE_URL=https://argo.example.comA registry path (
ARGOCD_TOKEN_REGISTRY_PATH) and base URL are not secrets, so they're fine to pass inline.
Do not place the registry file under
dist/—tsupbuilds withclean: trueand wipes that directory on every build.
The HTTP server listens on POST /mcp (127.0.0.1:3000 by default, see Network Exposure to widen it) with a GET /healthz liveness endpoint. To send a request, first initialize a session (capture the mcp-session-id response header), then call a tool, passing one of the registered base URLs as the argocdBaseUrl argument:
# 1. Initialize a session — note the mcp-session-id response header
curl -sD - http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'
# 2. Call a tool, reusing that session id
curl -s http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'mcp-session-id: <session-id-from-step-1>' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_applications","arguments":{"argocdBaseUrl":"https://argo-a.example.com"}}}'To avoid managing a session id, run in stateless mode (node dist/index.js http --stateless) so every POST /mcp is self-contained.
To update the TypeScript type definitions based on the latest Argo CD API specification:
Download the swagger.json file from the ArgoCD release page, for example here is the swagger.json link for ArgoCD v2.14.11.
Place the downloaded swagger.json file in the root directory of the argocd-mcp project.
Generate the TypeScript types from the Swagger definition by running the following command. This will create or overwrite the src/types/argocd.d.ts file:
pnpm run generate-typesUpdate the src/types/argocd-types.ts file to export the required types from the newly generated src/types/argocd.d.ts. This step often requires manual review to ensure only necessary types are exposed.
The project was initially created and donated by @jiachengxu, @imwithye, @hwwn, and @alexmt from Akuity.
create_application creates a new ArgoCD application in the specified namespace. The application.metadata.namespace field determines where the Application resource will be created (e.g., "argocd", "argocd-apps", or any custom namespace).
| Name | Required | Description | Default |
|---|---|---|---|
| application | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions creation without details on side effects, permissions, or failure modes. Carries full burden but provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, with no extraneous content. Efficient but could benefit from structured sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with complex nested input and no output schema, the description lacks return value info, success conditions, and error handling. Schema partially compensates but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema, noting that namespace determines where the Application resource is created. Schema already defines structure, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (new ArgoCD application), and specifies the namespace. It implicitly distinguishes from sibling tools by action type, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_application or sync_application. Missing prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_application deletes application. Specify applicationNamespace if the application is in a non-default namespace to avoid permission errors.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the application is located. Required if application is not in the default namespace. | |
| cascade | No | Whether to cascade the deletion to child resources | |
| propagationPolicy | No | Deletion propagation policy (e.g., "Foreground", "Background", "Orphan") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It merely states the action and warns about namespace permissions, but omits critical details like irreversibility, effects on child resources, or required permissions for the deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one states the core action, the other provides a practical tip. Both sentences earn their place without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should cover more context. It does not address return values, error conditions, prerequisites, or the irreversible nature of deletion. The description is too sparse for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters described). The description adds minimal value beyond the schema: it reinforces the namespace parameter's purpose but does not clarify applicationName, cascade, or propagationPolicy. The added context is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes an application, which is a specific verb-resource combination. It distinguishes from sibling tools like create_application or update_application. However, it does not elaborate on the scope or consequences of deletion, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a tip about specifying namespace to avoid permission errors. It offers no guidance on when to use delete versus alternative tools (e.g., sync_application, update_application) or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application returns application by application name. Optionally specify the application namespace to get applications from non-default namespaces.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on behavior such as error handling, default namespace behavior, or that it is a read-only operation. Only the optional namespace is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 17 words, front-loading the purpose and key behavior. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with two parameters and no output schema, the description is adequate but could benefit from specifying default namespace, error responses, or return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with only the namespace parameter having a description. The tool description adds that namespace is optional and for non-default namespaces but does not explain the applicationName parameter format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an application by name, with an optional namespace parameter. It distinguishes from siblings like list_applications by specifying retrieval of a single application by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using the namespace parameter for non-default namespaces but does not provide explicit when-to-use or when-not-to-use guidance compared to other tools like get_application_events or list_applications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_events returns events for application by application name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details beyond the basic purpose. It does not disclose pagination, ordering, time range, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the action. However, for better clarity, it could be structured with bullet points or more explicit details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage, no output schema, and no annotations, the description is incomplete. It does not specify the return type (list of events) or any event structure, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description only repeats the parameter name context ('by application name'), adding no format, constraints, or usage details. It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns events for an application by name, which is a specific verb-resource combination. It distinguishes from siblings like get_application (returns the app itself) and list_applications (lists apps). However, it lacks detail on what type of events are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_resource_events. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_managed_resources returns managed resources for application by application name with optional filtering. Use filters to avoid token limits with large applications. Examples: kind="ConfigMap" for config maps only, namespace="production" for specific namespace, or combine multiple filters.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| kind | No | Filter by Kubernetes resource kind (e.g., "ConfigMap", "Secret", "Deployment") | |
| namespace | No | Filter by Kubernetes namespace | |
| name | No | Filter by resource name | |
| version | No | Filter by resource API version | |
| group | No | Filter by API group | |
| appNamespace | No | Filter by Argo CD application namespace | |
| project | No | Filter by Argo CD project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of transparency. It warns about token limits for large applications, which is a behavioral insight, but does not clarify read-only nature, authentication requirements, or response structure. Partial but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: first states purpose, second advises filtering, third gives examples. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with high schema coverage and a clear return purpose. However, it lacks details about response format or pagination, which would be expected for a list of resources. No output schema is provided, so description should have filled that gap more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), and the description adds value by explaining why filters matter (token limits) and giving concrete examples (kind, namespace). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns managed resources for a given application with optional filtering, using specific verb and resource. It distinguishes from sibling tools like get_application and get_resources by focusing on managed resources and filtering capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using filters to avoid token limits with large applications, providing concrete examples. It does not mention when not to use this tool versus alternatives, but the guidance is clear and practical for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_resource_tree returns resource tree for application by application name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or authentication requirements. The description only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it highly concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but incomplete. It lacks details about the structure or content of the returned resource tree.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no extra meaning to the parameter 'applicationName' beyond what the schema states (a required string). No format, case sensitivity, or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a resource tree for an application by name. However, it does not differentiate from sibling tools like get_application_managed_resources or get_resources, which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_application_managed_resources, get_resources). The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_workload_logs returns logs for application workload (Deployment, StatefulSet, Pod, etc.) by application name and resource ref and optionally container name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes | ||
| container | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not mention potential limits, authorization needs, or whether the operation is read-only or destructive. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that captures the essence without extra words. It is front-loaded with the tool's purpose. However, it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what type of logs are returned (e.g., format, pagination). It does not describe the return value, leaving ambiguity. The tool has complex parameters (nested object) and the description does not cover all details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema parameters have descriptions. The description adds minimal meaning beyond parameter names (e.g., 'by application name and resource ref and optionally container name'). The nested resourceRef object lacks explanation of its fields despite a detailed schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves logs for application workloads, specifying the resource types and key parameters. It is specific about the verb and resource, but does not explicitly differentiate from sibling tools like get_application_events or get_resource_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as get_resource_events or get_application_events. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resource_actions returns actions for a resource that is managed by an application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions returning actions but does not confirm read-only nature, nor does it discuss permissions, side effects, or what happens if the resource is not found. The minimal information is insufficient for a safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, achieving conciseness. However, it could be improved with additional context without becoming verbose, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters including a nested object, no output schema, and no annotations. The description does not explain the return format or behavior beyond 'returns actions'. Given the complexity, the description lacks completeness and should provide more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only applicationNamespace has a description). The tool description does not add any meaning beyond the schema for the other parameters (applicationName, resourceRef). Since the description fails to compensate for the low coverage, the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns actions for a resource managed by an application, using a specific verb and resource. However, it does not distinguish from sibling tools like run_resource_action or get_resource_events, so it loses a point for lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as using it to list available actions before calling run_resource_action. This lack of context makes it harder for an AI agent to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resource_events returns events for a resource that is managed by an application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceUID | Yes | ||
| resourceNamespace | Yes | ||
| resourceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states it 'returns events', implying read-only behavior but does not explicitly confirm this, nor does it disclose any authorization needs, side effects, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence. While it is not formally structured, it conveys the core purpose efficiently without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what constitutes an event, the return format, or any preconditions, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), with only 'applicationNamespace' having a meaningful description. The tool description adds no additional meaning beyond the schema for the other four parameters, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns events for a resource managed by an application. However, it does not distinguish this from the sibling tool 'get_application_events', which might serve a similar purpose, potentially causing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'get_application_events', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resources return manifests for resources specified by resourceRefs. If resourceRefs is empty or not provided, fetches all resources managed by the application.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRefs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, permissions, or read-only nature. It only states it returns manifests, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear, no wasted words. Front-loaded with action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description indicates returns manifests. Covers main behavior but lacks details on error handling or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%. Description adds meaning for resourceRefs (optional, fetches all if empty) but does not clarify applicationName or applicationNamespace beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns manifests for resources specified by resourceRefs or all resources when empty. It distinguishes from sibling tools like list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to get manifests) but does not explicitly compare to siblings. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_applications returns list of applications
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search applications by name. This is a partial match on the application name and does not support glob patterns (e.g. "*"). Optional. | |
| limit | No | Maximum number of applications to return. Use this to reduce token usage when there are many applications. Optional. | |
| offset | No | Number of applications to skip before returning results. Use with limit for pagination. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it returns a list, omitting details like ordering, default limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices informativeness; it is under-specified rather than efficiently compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools for specific operations and the lack of an output schema, the description fails to clarify result ordering, pagination behavior, or default limits, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage, so baseline is 3. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name, 'list_applications returns list of applications,' without specifying any filtering or scope, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like get_application or search functions, and no context for typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_resource_action runs an action on a resource
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose whether the action is destructive, requires permissions, or has side effects. The lack of behavioral details leaves the agent in the dark about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but at the expense of clarity. It could be improved by adding a few more sentences about purpose and usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, nested object, no output schema), the description is inadequate. It does not explain what actions are valid, what the tool returns, or how to construct the resourceRef. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only applicationNamespace has a description). The tool description adds no additional meaning to parameters; it merely repeats the tool name. The nested resourceRef object is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'runs an action on a resource' but is extremely vague. It does not specify what kind of resource, what actions are possible, or how it differs from sibling tools like sync_application or get_resource_actions. The purpose is unclear without further inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., need to use get_resource_actions first to see available actions) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sync_application syncs application. Specify applicationNamespace if the application is in a non-default namespace to avoid permission errors.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the application is located. Required if application is not in the default namespace. | |
| dryRun | No | Perform a dry run sync without applying changes | |
| prune | No | Remove resources that are no longer defined in the source | |
| revision | No | Sync to a specific revision instead of the latest | |
| syncOptions | No | Additional sync options (e.g., ["CreateNamespace=true", "PrunePropagationPolicy=foreground"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., whether the operation is destructive, permission requirements, side effects). The description is far too brief to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) with no wasted words, but it is too brief given the complexity of the tool (6 parameters, sync operation). It could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a moderate parameter count, the description is incomplete. It fails to explain what 'sync' entails, return behavior, errors, or any important context needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the baseline is 3. The description adds some context for 'applicationNamespace' (permission errors), but adds no meaning beyond the schema for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'syncs' and the resource 'application'. It communicates the core function, but does not differentiate from sibling tools like 'update_application' or 'create_application', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is about specifying 'applicationNamespace' for non-default namespaces to avoid errors. No guidance on when to use this tool versus alternatives, nor prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_application updates application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| application | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits. For example, it does not specify if this is a full replace (PUT) or partial update (PATCH), whether it triggers a sync, or what happens to omitted fields. With zero annotation coverage, the description carries the full burden and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 3 words, but this is not concise—it is under-specified. It wastes the opportunity to provide any useful context. A good description should be front-loaded with purpose and key constraints, but this is virtually empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema (with required metadata, spec, etc.) and no output schema, the description is completely inadequate. The agent needs to know what fields are mutable, the effect of the update, and any side effects. None is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the two required parameters (applicationName, application). Despite some inline schema descriptions for nested fields, the context signals 0% schema description coverage, meaning the tool's own description must compensate, but it does not mention any parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'update_application updates application'. It merely restates the tool name and the implied action without specifying what exactly is updated (e.g., ArgoCD application resource, configuration, etc.). No verb+resource clarity beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like create_application or sync_application. Does not mention that it is for updating existing applications only, or what scenarios warrant an update vs. a sync.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_application2 fields changedInput schema / properties / application / properties / metadata / properties / namespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / application / properties / metadata / properties / namespace / minLengthAdded value: +1delete_application3 fields changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the application is located. Required if application is not in the default namespace.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / cascadeAdded value: +{
+ "description": "Whether to cascade the deletion to child resources",
+ "type": "boolean"
+}Input schema / properties / propagationPolicyAdded value: +{
+ "description": "Deletion propagation policy (e.g., \"Foreground\", \"Background\", \"Orphan\")",
+ "type": "string"
+}get_application1 field changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer.",
+ "minLength": 1,
+ "type": "string"
+}get_application_workload_logs4 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1Input schema / properties / containerAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "applicationName",
- "applicationNamespace",
- "resourceRef"
-]New value: +[
+ "applicationName",
+ "applicationNamespace",
+ "resourceRef",
+ "container"
+]get_resource_actions2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1get_resource_events2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1get_resourceslist_applications2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Maximum number of applications to return. Use this to reduce token usage when there are many applications. Optional.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Number of applications to skip before returning results. Use with limit for pagination. Optional.",
+ "minimum": 0,
+ "type": "integer"
+}run_resource_action2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1sync_application5 fields changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the application is located. Required if application is not in the default namespace.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / dryRunAdded value: +{
+ "description": "Perform a dry run sync without applying changes",
+ "type": "boolean"
+}Input schema / properties / pruneAdded value: +{
+ "description": "Remove resources that are no longer defined in the source",
+ "type": "boolean"
+}Input schema / properties / revisionAdded value: +{
+ "description": "Sync to a specific revision instead of the latest",
+ "type": "string"
+}Input schema / properties / syncOptionsAdded value: +{
+ "description": "Additional sync options (e.g., [\"CreateNamespace=true\", \"PrunePropagationPolicy=foreground\"])",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}update_application2 fields changedInput schema / properties / application / properties / metadata / properties / namespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / application / properties / metadata / properties / namespace / minLengthAdded value: +1create_applicationdelete_applicationget_applicationget_application_eventsget_application_managed_resourcesget_application_resource_treeget_application_workload_logsget_resource_actionsget_resource_eventslist_applicationsrun_resource_actionsync_applicationupdate_applicationEach tool targets a distinct aspect of ArgoCD application management. While get_application_events and get_resource_events could be confused, descriptions clarify their scope. Overall, purposes are clearly separated.
All tools use consistent snake_case with verb_noun pattern (e.g., create_application, get_application_events). The naming is predictable and follows a clear convention.
14 tools is well-scoped for an ArgoCD MCP server, covering CRUD operations, synchronization, logs, events, and resource management without being excessive.
The tool set covers core application lifecycle (CRUD, sync, logs, events) and resource management. Minor gaps like rollback or version history are missing, but the surface is largely complete for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/argoproj-labs/mcp-for-argocd'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
