Skip to main content
Glama
vish288

mcp-argocd

by vish288
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Argocd Create Application

argocd_create_application

Create an Argo CD application from flattened parameters, including repo, project, path or chart, sync, and destination settings. Set upsert=True to update it if it already exists.

Instructions

Create an application from flattened parameters. Use patch for anything this does not cover.

Returns the created application, slim. Idempotent only with upsert=True.

Input Schema

NameRequiredDescriptionDefault
nameYesNew application name
pathNoPath within the repo (or use chart)
chartNoHelm chart name (or use path)
pruneNoPrune on auto-sync (needs auto_sync)
labelsNoApplication labels
upsertNoUpdate if it already exists
projectYesProject to create it in
repo_urlYesSource repository URL
validateNoValidate the manifests
auto_syncNoEnable automated sync
dest_nameNoDestination cluster name
self_healNoSelf-heal on drift (needs auto_sync)
dest_serverNoDestination cluster API URL
sync_optionsNoSync options list
app_namespaceNoOverride appNamespace; defaults to ARGOCD_APP_NAMESPACE
dest_namespaceNoDestination namespace
helm_parametersNoHelm params as k=v
target_revisionNoBranch, tag, or chart versionHEAD
create_namespaceNoAdd CreateNamespace=true
helm_value_filesNoHelm value file paths
kustomize_imagesNoKustomize image overrides
helm_release_nameNoHelm release name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds genuinely non-redundant behavior: the result is returned as a slimmed application, and the operation is idempotent only when upsert=True. It does not discuss side effects on the destination cluster or auto-sync consequences, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, no filler; the core action and its parameter model come first, then the alternative tool, then the return/idempotency note. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 22-parameter creation tool with 100% schema coverage and no output schema, the description covers the key non-schema facts: return shape, idempotency, and the fallback tool. Remaining gaps (auth/permission needs, whether creation triggers a sync) are minor given the annotation and schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 22 parameters, so the schema already documents each field including upsert and its meaning. The description only restates the upsert idempotency relationship, adding no syntax, format, or dependency detail beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an application') and immediately scopes it ('from flattened parameters'), which tells the agent this is the declarative/patchy path rather than an apply. It routes away from the sibling argocd_patch_application for uncovered fields, so it is distinguishable without opening the schema, though the phrase 'flattened parameters' is slightly jargon-like.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names an explicit alternative ('Use patch for anything this does not cover') and a conditional behavior ('Idempotent only with upsert=True'), which is real when-to-use guidance. It stops short of a full when/when-not boundary against siblings like argocd_generate_applicationset or argocd_sync_application, so it is clear context without exhaustive exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools