Configs Update

Config Update & Lifecycle

You’re using a skill that will guide you through updating, retiring, and deleting configs and their variations. Your job is to understand the current state of the config, make the changes, and verify the result.

Prerequisites

This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.

Required MCP tools:

• get-agent-configs with configKey – understand current state before making changes; add section: "health" to assess config health (detects missing models, orphaned tools, empty configs)
• update-agent-config with resource: "config" – update config metadata (name, description, tags, default variation, maintainer)
• update-agent-config with resource: "variation" – update variation model, prompts, or parameters
• update-agent-config with resource: "targeting" – turn a config’s targeting off in an environment to take it out of service

Optional MCP tools:

• delete-agent-config with resource: "config" – permanently delete a config (irreversible)
• delete-agent-config with resource: "variation" – permanently delete a variation (irreversible)

Core Principles

1. Fetch Before Changing: Always check the current state before modifying
2. Verify After Changing: Fetch the config again to confirm updates were applied
3. Turn Off Before Deleting: Configs cannot be archived. Turning targeting off is reversible; deletion is not

Workflow

Step 1: Assess Health and Understand Current State

Start with get-agent-configs (configKey, section: "health") to get a structured health assessment. This detects:

• Variations with no model (show as “NO MODEL” in the UI)
• Variations with neither instructions nor messages
• Orphaned tool references (tools attached that don’t exist in the project)
• Configs with no variations at all

The health verdict (healthy, warning, unhealthy) helps you prioritize what to fix.

Then use get-agent-configs to review the full detail:

• Current mode (agent or completion)
• Existing variations and their models
• Current instructions or messages
• Attached tools and parameters

To restore an earlier prompt or model, call get-agent-configs with section: "versions" and the variationKey to list that variation’s saved versions, newest first, then pass the chosen version’s model and messages to update-agent-config with resource: "variation".

Step 2: Make the Update

Update config metadata – Use update-agent-config with resource: "config":

• Change name or description
• Add or replace tags
• Set defaultVariationKey (what new environments serve by default; existing environments keep their fallthrough, so change those with resource: "targeting")
• Set the maintainer with maintainerId or maintainerTeamKey (not both; an empty string removes it)

Configs cannot be archived: the tool rejects archived.

Update a variation – Use update-agent-config with resource: "variation" and the variationKey (requires confirm: true; pass it after the user agrees):

• Switch model (provide new modelConfigKey and modelName)
• Rename it with variationName
• Change instructions or messages
• Tune parameters (temperature, max_tokens, etc.)
• Attach or detach tools with the top-level tools array

Retire a config – Configs cannot be archived. To take one out of service but keep it recoverable, turn its targeting off with update-agent-config, resource: "targeting", the env, on: false, and confirm: true (pass it after the user agrees). This is the preferred way to retire a config:

• It is reversible (turn targeting back on with on: true)
• The config, its variations, and their version history are preserved
• It is per environment: check get-agent-configs with section: "status" to see where the config is live, and ask which environments to turn off rather than guessing
• When a user says “remove”, “retire”, “decommission”, or “no longer need”, default to turning targeting off unless they explicitly say “delete permanently”

Delete – Use delete-agent-config with resource: "config" or resource: "variation" (irreversible, requires confirm: true). Always suggest turning targeting off first. Only proceed with deletion if the user explicitly confirms they want permanent, irreversible removal.

Step 3: Verify

Use get-agent-configs to confirm the response shows your updated values.

Report results:

• Update applied successfully
• Config reflects changes
• Flag any issues or rollback if needed

What NOT to Do

• Don’t update production configs without testing in another variation first
• Don’t change multiple things at once – make incremental changes
• Don’t skip verification
• Don’t delete without explicit user confirmation – always suggest turning targeting off first
• Don’t pass archived – configs cannot be archived and the tool rejects it
• Don’t retry an update because the API response doesn’t echo back the exact values you sent – verify with get-agent-configs instead

More resources

To learn more about creating and managing variations, read Create and manage config variations (opens in a new tab).

Related Skills

• configs-variations – Create variations to test changes side-by-side
• tools – Update tool attachments