Kiro CLI + ArgoCD MCP: Manage GitOps from Your Terminal

Managing ArgoCD applications typically means writing Application YAML, configuring sync policies, and switching between the CLI and UI. It works, but there's a better way to do it.

With Kiro CLI and the ArgoCD MCP server, you can do all of that using natural language from your terminal — create apps, sync them, check health, view resource trees.

Deploying to Kubernetes Before GitOps

Before ArgoCD, deploying to Kubernetes was mostly manual. You'd write your manifests, run kubectl apply, and hope it works. A typical workflow:

1. Write Deployment, Service, ConfigMap YAML by hand


2. 
   kubectl apply -f from your laptop


3. Verify the resources are running in the right namespace


4. Commit the manifests to Git (if you remember)


5. Repeat across environments, hoping cluster state and repo stay in sync

Some teams graduated to Helm charts, which helped with templating but didn't solve the drift problem. Others wrote custom CI/CD pipelines that ran kubectl apply on merge — better, but still push-based and fragile.

Then GitOps came along and flipped the model. Instead of pushing changes to the cluster, you declare the desired state in Git and let a controller pull it in. ArgoCD is the most popular implementation of this pattern — it watches your Git repo, compares it to what's running in the cluster, and reconciles the difference automatically.

The cluster state problem is solved. The day-to-day management — writing Application manifests, configuring sync policies, navigating the UI — is where an agentic approach can help.

What We're Building

By the end of this article, you'll have:

• Kiro CLI connected to your ArgoCD instance via the ArgoCD MCP server


• The ability to create, sync, and monitor ArgoCD applications using natural language directly from your terminal


• A workflow for generating Application manifests with automated sync and health checks

The Setup

Prerequisites

• An EKS cluster (or any Kubernetes cluster) with ArgoCD installed


• An ArgoCD API token (docs for creating one)


• 
  Kiro CLI installed


• Node.js v18+

If you don't have ArgoCD running yet, the quickest path on EKS is:

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Then port-forward to access it locally:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Getting Your ArgoCD API Token

You need an API token for the MCP server to authenticate with ArgoCD. From the ArgoCD UI:

1. Go to Settings → Accounts → admin
   


2. Click Generate New under Tokens


3. Copy the token — you'll need it in the next step

Or via CLI:

argocd account generate-token --account admin

Connecting Kiro CLI to ArgoCD

The ArgoCD MCP server is what makes this work. MCP (Model Context Protocol) lets Kiro communicate with external services through standardized tool interfaces. The ArgoCD MCP server exposes ArgoCD's API as tools that Kiro can call — list apps, create apps, sync, get resource trees, fetch logs, and more.

I prefer to wire the MCP server into a Kiro Custom Agent rather than a global mcp.json. This way the agent has a focused prompt, scoped tools, and the ArgoCD connection is self-contained — easy to share with the team or drop into any project.

Create .kiro/agents/argocd-agent.json in your project:

{

  "name": "argocd-agent",

  "description": "Manages ArgoCD applications via natural language — create, sync, monitor, and troubleshoot GitOps deployments",

  "prompt": "You are a GitOps specialist. You manage ArgoCD applications on Kubernetes clusters. Use the ArgoCD MCP tools to list, create, update, sync, and monitor applications. Always confirm destructive actions before executing them.",

  "mcpServers": {

    "argocd": {

      "command": "npx",

      "args": [

        "argocd-mcp@latest",

        "stdio"

      ],

      "env": {

        "ARGOCD_BASE_URL": "https://localhost:8080",

        "ARGOCD_API_TOKEN": "<your-argocd-api-token>"

      }

    }

  },

  "tools": [

    "read",

    "@argocd"

  ],

  "allowedTools": [

    "read",

    "@argocd"

  ]

}

If your ArgoCD instance uses self-signed certificates (common with port-forwarding), add "NODE_TLS_REJECT_UNAUTHORIZED": "0" to the env block inside mcpServers.argocd.env. Only do this in development.

For safer use in production, add "MCP_READ_ONLY": "true" to the env block — this disables create, update, delete, and sync operations.

Start Kiro CLI with the ArgoCD agent:

cd my-project

kiro-cli --agent argocd-agent

You can verify the MCP server loaded by running /mcp in the chat session — you should see argocd listed with its available tools.

Why a Custom Agent? Subagents and Context Management

There's another reason I use a custom agent instead of configuring all MCPs and tools in the default agent: subagents. In Kiro CLI, a parent agent can spawn custom agents as subagents — each running in its own context with its own tools. The subagent does its work in its own isolated context and returns only the result to the parent agent.

This matters for context window efficiency. Imagine a platform-engineer parent agent that handles broad infrastructure tasks. When it needs to interact with ArgoCD, it spawns argocd-agent as a subagent. The ArgoCD MCP tools, API responses, and resource trees only live in the subagent's context — they never bloat the parent's context window. Once the subagent returns the result, that context is freed.

You: Check if all apps are healthy, then review the Terraform plan for the new VPC



platform-engineer agent:

  → spawns argocd-agent: "List all applications and check their health"

    ← returns: "3 apps, all Healthy and Synced"

  → reviews Terraform plan with its own tools (clean context, no ArgoCD noise)

You can even pre-trust the ArgoCD agent so it runs without permission prompts:

{

  "name": "platform-engineer",

  "description": "Parent agent for infrastructure and platform tasks",

  "tools": ["read", "write", "shell", "aws", "subagent"],

  "toolsSettings": {

    "subagent": {

      "availableAgents": ["argocd-agent", "terraform-agent"],

      "trustedAgents": ["argocd-agent"]

    }

  }

}

This is the real payoff of defining ArgoCD as a custom agent — it becomes a composable, context-efficient building block in a larger workflow.

Creating an ArgoCD Application with Natural Language

Instead of writing an Application manifest by hand, just tell Kiro what you want:

Create a new ArgoCD application called guestbook that deploys from the repo https://github.com/argoproj/argocd-example-apps, path guestbook, targeting the default namespace on the in-cluster destination

Kiro uses the create_application Tool from the ArgoCD MCP server. Kiro handles the API call and creates the application directly in ArgoCD.

The equivalent YAML that ArgoCD creates under the hood looks like this:

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: guestbook

  namespace: argocd

spec:

  project: default

  source:

    repoURL: https://github.com/argoproj/argocd-example-apps

    targetRevision: HEAD

    path: guestbook

  destination:

    server: https://kubernetes.default.svc

    namespace: default

Here's what each field does:

• 
  project: The ArgoCD project this app belongs to. default works for most cases.


• 
  source.repoURL: The Git repository containing your manifests.


• 
  source.path: The directory within the repo where the Kubernetes manifests live.


• 
  source.targetRevision: Which branch/tag/commit to track. HEAD follows the default branch.


• 
  destination.server: The cluster to deploy to. https://kubernetes.default.svc means "this cluster."


• 
  destination.namespace: Where the resources get created.

Adding Automated Sync

By default, ArgoCD applications are created without auto-sync — you have to manually trigger syncs. That's fine for production, but for dev/staging environments, you usually want changes to deploy automatically when you push to Git.

Update the guestbook application to enable automated sync with self-healing and auto-pruning

Kiro calls update_application and configures the sync policy. Here's what those settings mean:

• 
  Automated sync: ArgoCD automatically syncs when it detects the Git repo has changed


• 
  Self-healing: If someone manually changes a resource in the cluster (kubectl edit, etc.), ArgoCD reverts it back to match Git


• 
  Auto-prune: If you remove a resource from Git, ArgoCD deletes it from the cluster too

The equivalent sync policy in YAML:

spec:

  syncPolicy:

    automated:

      prune: true

      selfHeal: true

    syncOptions:

      - CreateNamespace=true

Checking Application Health

Once the app is synced, you want to know if it's actually healthy — are the pods running? Did the deployment roll out successfully?

Check the health of the guestbook application

Kiro calls get_application and returns the sync status, health status, and any conditions. You'll see something like:

• 
  Sync Status: Synced


• 
  Health Status: Healthy


• 
  Resources: Deployment (Healthy), Service (Healthy)

If something is wrong, you can dig deeper:

Show me the resource tree for the guestbook application

This calls get_application_resource_tree and shows the full hierarchy — the Application owns a Deployment, which owns a ReplicaSet, which owns Pods. If a pod is in CrashLoopBackOff, you'll see it here.

Get the logs for the failing pod in the guestbook application

Kiro calls get_application_workload_logs and pulls the logs directly, so you don't need to kubectl logs into the right namespace and pod name.

Syncing and Monitoring

When you need to manually trigger a sync (maybe you have auto-sync disabled in production):

Sync the guestbook application

Show me which applications are out of sync

List all ArgoCD applications in my cluster

Each of these maps to a specific MCP tool (sync_application, list_applications, etc.) and Kiro handles the API calls behind the scenes.

The Full Workflow

Here's what a typical session looks like, end to end:

You: List all ArgoCD applications

Kiro: [calls list_applications] You have 3 applications: 

      frontend (Synced/Healthy), backend (OutOfSync/Healthy), 

      monitoring (Synced/Degraded)



You: Sync the backend application

Kiro: [calls sync_application] Sync initiated for backend. 

      Revision: abc123f



You: Check the health of the monitoring application

Kiro: [calls get_application] monitoring is Degraded. 

      The prometheus-server Deployment has 0/1 ready replicas.



You: Show me the logs for the prometheus-server in monitoring

Kiro: [calls get_application_workload_logs] 

      Error: no persistent volume claim found...

All from one terminal session, instead of remembering commands like argocd app get monitoring -o yaml | grep health.

Try It Yourself

1. Install Kiro CLI: curl -fsSL https://cli.kiro.dev/install | bash
   


2. Set up the ArgoCD MCP server config as shown above


3. Start a chat session with kiro-cli and try: List all ArgoCD applications in my cluster
   

If you've been managing ArgoCD through the UI or memorizing CLI flags, try it on a staging cluster and see how it feels.