create-flag should expose defaults.offVariation and defaults.onVariation

[jprobst21]

Summary

When creating a multivariate flag via the create-flag MCP tool, there's no way to specify defaults.offVariation (or defaults.onVariation). LaunchDarkly's API auto-assigns the off variation to the last variation in the list, which is unsafe for multivariate flags where variation order has semantic meaning.

Repro

// Tool call
{
  "projectKey": "<project>",
  "key": "myVersionFlag",
  "name": "My Version Flag",
  "kind": "multivariate",
  "variations": [
    { "value": 3, "name": "v3 (current GA)" },
    { "value": 4, "name": "v4 (placeholder for next bump)" }
  ],
  "temporary": false
}

Actual behavior

After creation, defaults.offVariation is 1 (= v4). With targeting OFF in any environment (which is the default state for new flags), the flag serves v4 to everyone. For a versioning flag where v4 doesn't exist yet in code, this would route every request through a non-existent code path.

Expected behavior

Either:

1. The create-flag tool accepts optional defaults.offVariation / defaults.onVariation parameters (mirroring the LD REST API's defaults object), so callers can specify the safe variation explicitly. Preferred.
2. The off variation defaults to index 0 (the first variation) rather than the last, with a note in the tool description.

Workaround

The MCP doesn't expose updateOffVariation either — update-targeting-rules rejects that instruction kind. Today the only workaround is to fix the off variation manually in the LaunchDarkly UI per environment, which defeats the purpose of an MCP-driven flag-creation flow.

Related gap

Even after fixing per-env offVariation in the UI, the flag-level defaults.offVariation (the template used when new envs get created) remains pointing at the last variation. There's no MCP path to fix that either. Both should be addressable via the same tool call.

Why this matters

The create-flag skill (launchdarkly-flag-create) recommends multivariate integer flags as the right pattern for things like schema versioning, where variation order encodes meaning ("3 is current, 4 is the next placeholder"). That pattern is unsafe today because the off variation silently defaults to the placeholder.