Start free →

LaunchDarkly

Connecting LaunchDarkly lets an agent move a flag for you, raising a rollout one stage at a time and putting it back if errors show up. An agent can also read a flag long after a change shipped, so a flag that has finished its job gets raised for cleanup instead of sitting there forever.

Before you start

You need a LaunchDarkly account with access to the projects and environments you want agents to read. LaunchDarkly's own guide is LaunchDarkly hosted MCP server.

There is no token to create. You authorize the connection by signing in to LaunchDarkly in your browser.

LaunchDarkly does not offer its hosted server in the EU or federal instances, so an account on either cannot connect this way.

Connect it

  1. In SetForth, open your project, then Integrations.
  2. Choose LaunchDarkly.
  3. Leave the server URL as https://mcp.launchdarkly.com/mcp/launchdarkly.
  4. Choose Connect. You go to LaunchDarkly, sign in, and approve the connection there.
  5. LaunchDarkly sends you back to SetForth and the integration is connected.

LaunchDarkly's consent screen may warn that you are approving an unverified application. That is expected. It describes the OAuth client SetForth registers for your connection, and the connection is safe to approve.

SetForth asks LaunchDarkly for write access at that moment, because the grant is settled when the connection is first made and cannot be widened later. What agents may call is a separate setting, Tool access on the integration's page. A LaunchDarkly connection starts on All tools, because three of the four follow-ups it adds move a flag. Narrow it to Read-only tools if you want agents to report on flags without ever changing one.

What agents can check

Connecting a feature flags tool adds four follow-ups. One reads a flag:

  • No stale flags reports a flag that has served one variation to everyone long enough that it and its dead branch can be removed.

Three write to a flag:

  • Ensure a flag exists creates the flag a change ships behind, and leaves it alone when it is already there. Put it on an early task so the flag is in place before the code that reads it deploys.
  • Set rollout percentage moves a feature flag to an explicit served percentage, recording the percentage it replaced so the stage can be undone.
  • Revert rollout percentage returns a feature flag to a given served percentage, undoing a stage of a rollout.

You name the flag, the environment, and how long to wait when you add a follow-up during planning. On a check you can leave the flag empty and the agent works out which one the change shipped behind. The three that write always need the flag and the environment, and the two that move a percentage need the percentage to serve.

Ramp a rollout in stages

A plan can raise a flag through percentages you choose instead of going straight to everyone. A ramp is a series of stages on one task: each stage sets the next percentage, and a stage that asks to be watched gets an error check over that percentage for a window before the next stage goes out.

5%    watch for 6 hours
25%   watch for 6 hours
50%   watch for 6 hours
100%

Each window starts when its own stage goes out, not when the code merged, so equal windows give you equally spaced stages. A slow deploy pushes the whole ramp back rather than collapsing the stages into one another.

When errors show up

Each stage says for itself what watching means, under Watch for errors between stages. There are three modes:

  • Off is the default. No check is inserted and stages advance on their windows alone.
  • Stop halts the ramp on a failing check. No later stage runs and the flag keeps serving the last percentage that passed.
  • Revert halts the ramp the same way, and returns the flag to 0% so the change reaches nobody.

A watched stage observes for 6 hours unless you name a different window. The window is the check's, not a delay on the stage itself.

Under Stop and Revert the ramp ends where the check failed, so a regression never reaches a larger share of traffic than the stage that found it. The task then waits for you, with the percentage the stage replaced recorded on it and a revert recorded alongside the check that caused it.

Watching also needs an error monitoring integration connected. With none, a stage that asked for Stop or Revert still sets its percentage and then behaves as though it were set to Off.

What the ramp needs

Moving a flag is a write, so a ramp needs Tool access left on All tools, where every LaunchDarkly connection starts. Narrow it to Read-only tools and the first stage is refused: the ramp never starts and the task asks for a person.

An environment that requires approval for flag changes answers the write with an approval request instead of applying it. The percentage did not move, so the stage fails rather than passing, and the ramp stops there. Ramp in an environment that does not gate flag changes. If the one you want to ramp in does gate them, change the flag yourself in LaunchDarkly instead.

Who the connection belongs to

The connection carries the access of whoever authorized it. Its page in SetForth shows who that was. If they leave or lose access in LaunchDarkly, the integration stops working and Reconnect hands it to someone else.