Skip to main content
Glama

update_application

Modify an ArgoCD application by updating its project, repository, path, destination, revision, or sync settings. Automate syncing, pruning, or self-healing, and validate changes for accuracy.

Instructions

Update an existing application in ArgoCD

Args:
    name: The application name to update (required)
    project: New project name (optional)
    repo_url: New Git repository URL (optional)
    path: New path within the repository (optional)
    dest_server: New destination K8s API server URL (optional)
    dest_namespace: New destination namespace (optional)
    revision: New Git revision (optional)
    automated_sync: Enable/disable automated sync (optional)
    prune: Enable/disable auto-pruning resources (optional)
    self_heal: Enable/disable self-healing (optional)
    validate: Whether to validate the application

Returns:
    The updated application details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
automated_syncNo
dest_namespaceNo
dest_serverNo
nameYes
pathNo
projectNo
pruneNo
repo_urlNo
revisionNo
self_healNo
validateNo

Implementation Reference

  • The primary handler function for the 'update_application' tool. It fetches the current application details from ArgoCD, applies the provided optional updates to project, source (repo, path, revision), destination (server, namespace), and sync policy fields, then performs a PUT request to update the application via the API client.
    async def update_application(
        name: str,
        project: Optional[str] = None,
        repo_url: Optional[str] = None,
        path: Optional[str] = None,
        dest_server: Optional[str] = None,
        dest_namespace: Optional[str] = None,
        revision: Optional[str] = None,
        automated_sync: Optional[bool] = None,
        prune: Optional[bool] = None,
        self_heal: Optional[bool] = None,
        validate: bool = True,
    ) -> Dict[str, Any]:
        """
        Update an existing application in ArgoCD
    
        Args:
            name: The application name to update (required)
            project: New project name (optional)
            repo_url: New Git repository URL (optional)
            path: New path within the repository (optional)
            dest_server: New destination K8s API server URL (optional)
            dest_namespace: New destination namespace (optional)
            revision: New Git revision (optional)
            automated_sync: Enable/disable automated sync (optional)
            prune: Enable/disable auto-pruning resources (optional)
            self_heal: Enable/disable self-healing (optional)
            validate: Whether to validate the application
    
        Returns:
            The updated application details
        """
        # First get the current application details
        success, app_data = await make_api_request(f"applications/{name}")
        if not success:
            return {
                "error": app_data.get(
                    "error", f"Failed to get current application details for '{name}'"
                )
            }
    
        # Update fields only if provided
        if project:
            app_data["spec"]["project"] = project
    
        if repo_url or path or revision:
            # Update source fields
            source = app_data["spec"].get("source", {})
            if repo_url:
                source["repoURL"] = repo_url
            if path:
                source["path"] = path
            if revision:
                source["targetRevision"] = revision
            app_data["spec"]["source"] = source
    
        if dest_server or dest_namespace:
            # Update destination fields
            destination = app_data["spec"].get("destination", {})
            if dest_server:
                destination["server"] = dest_server
            if dest_namespace:
                destination["namespace"] = dest_namespace
            app_data["spec"]["destination"] = destination
    
        # Update sync policy if any of those parameters are provided
        if automated_sync is not None or prune is not None or self_heal is not None:
            sync_policy = app_data["spec"].get("syncPolicy", {})
            automated = (
                sync_policy.get("automated", {}) if "automated" in sync_policy else None
            )
    
            # Create automated section if it doesn't exist but should
            if automated_sync is True and automated is None:
                automated = {}
                sync_policy["automated"] = automated
    
            # Remove automated section if it exists but should not
            elif automated_sync is False and automated is not None:
                del sync_policy["automated"]
    
            # Update automated settings
            if automated is not None:
                if prune is not None:
                    automated["prune"] = prune
                if self_heal is not None:
                    automated["selfHeal"] = self_heal
    
            app_data["spec"]["syncPolicy"] = sync_policy
    
        # Add query parameters
        params = {}
        if validate:
            params["validate"] = "true"
    
        # Update the application
        success, response = await make_api_request(
            f"applications/{name}", method="PUT", data=app_data, params=params
        )
    
        if success:
            logger.info(f"Application '{name}' updated successfully")
            return response
        else:
            logger.error(f"Failed to update application '{name}': {response.get('error')}")
            return {
                "error": response.get("error", f"Failed to update application '{name}'")
            }
  • server.py:44-44 (registration)
    Registers the update_application function from tools.applications as an MCP tool using the FastMCP tool decorator.
    mcp.tool()(applications.update_application)
  • server.py:18-18 (registration)
    Imports the applications module containing the update_application handler for registration.
    import tools.settings as settings
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool updates an existing application and returns details, it doesn't describe important behaviors like whether changes are immediate or require sync, what happens if validation fails, or if there are rate limits or side effects. This leaves significant gaps for a mutation tool.

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

Conciseness4/5

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

The description is well-structured with clear sections (Args, Returns) and uses bullet points effectively. It's appropriately sized for an 11-parameter tool, though the opening sentence could be more front-loaded with key usage information rather than just stating the basic purpose.

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

Completeness3/5

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

Given the complexity (11 parameters, mutation operation, no annotations, no output schema), the description does a decent job but has significant gaps. It thoroughly documents parameters but lacks behavioral context, error handling information, and doesn't explain what 'updated application details' actually contains. For a mutation tool with this complexity, more completeness would be expected.

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

Parameters5/5

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

The description provides excellent parameter semantics, listing all 11 parameters with clear explanations of what each represents (e.g., 'New Git repository URL', 'Enable/disable automated sync'). This adds substantial value beyond the input schema, which has 0% description coverage and only provides titles like 'Dest Server' without context.

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?

The description clearly states the verb ('Update') and resource ('an existing application in ArgoCD'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'create_application' or 'sync_application' in terms of when to use each, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'create_application' or 'sync_application'. It also lacks information about prerequisites (e.g., whether the application must exist) or constraints (e.g., permissions needed).

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/severity1/argocd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server