`update_color_variable` rejects all `existing_variable_id` aliasing

[cohesiveneal]

TL;DR

The Webflow MCP's variable_tool → update_color_variable action's existing_variable_id parameter always returns "not found," even when passed a variable ID that is demonstrably valid — including an ID currently in active use as a native alias elsewhere in the same site. Every combination tested (same-collection, cross-collection, Relume-seeded target, MCP-created target, solid-value target) fails. The same action's custom_value and static_value paths work correctly. Workaround is custom_value + CSS var(...), but it produces a "Custom value" instead of a true native alias — losing the typed reference and breaking silently if the target variable's cssName ever changes.

Summary

The variable_tool → update_color_variable action's value.existing_variable_id field fails on every target variable tested, including variables that are demonstrably valid alias targets currently in use elsewhere in the same site.

custom_value and static_value on the same action work correctly.

Environment

• Webflow MCP version: 1.0.0 (per developer docs URL)
• Date: 2026-04-15
• Site ID: [SITE ID]
• Collection involved: Themes (collection-6df1d4d5-d11b-a74a-fcf2-f32116c72fc1)
• Client: Claude (via Anthropic's MCP integration)
• Auth: OAuth, Designer-scope tools (Webflow Designer tab active and in foreground during tests)

Expected behavior

Calling update_color_variable with value: { existing_variable_id: "<valid variable id>" } should set a native alias from the updated variable to the referenced variable — matching the Webflow Designer UI's "alias" behavior, and matching how existing native aliases are stored in the site's JSON data ("value": { "id": "<target id>" }).

Actual behavior

Every existing_variable_id call fails with one of two error messages:

• "Variable <id> not found for updating color variable <id>" (when the target is in a different collection, OR in some cases the same collection)
• "Error updating color variable <id> in collection <id>" (when target is in same collection)

The referenced target IDs demonstrably exist — they can be retrieved with get_variables / query_variables and render correctly when used as native aliases via other code paths.

Minimal reproduction

Context

Site has two color variables:

Source variable (in Themes collection):

{
  "id": "variable-089e73b1-7358-9339-d83c-b98312b53423",
  "name": "Background/secondary",
  "type": "Color",
  "cssName": "--_themes---background--secondary",
  "value": { "type": "custom", "value": "var(--_primitives---brand--sky-50)" }
}

Known-valid alias target (in Primitives collection) — proven valid because Background/primary in the same site currently has "value": { "id": "relume-variable--neutral-white" } as its native alias and renders correctly:

{
  "id": "relume-variable--neutral-white",
  "name": "Colors/White",
  "type": "Color",
  "cssName": "--_primitives---colors--white",
  "value": "#fff"
}

Failing call

{
  "siteId": "[SITE ID]",
  "actions": [{
    "label": "alias_to_neutral_white",
    "update_color_variable": {
      "variable_collection_id": "collection-6df1d4d5-d11b-a74a-fcf2-f32116c72fc1",
      "variable_id": "variable-089e73b1-7358-9339-d83c-b98312b53423",
      "value": { "existing_variable_id": "relume-variable--neutral-white" }
    }
  }]
}

Response

[{
  "status": "error",
  "message": "Variable relume-variable--neutral-white not found for updating color variable variable-089e73b1-7358-9339-d83c-b98312b53423"
}]

Workaround that succeeds

Replacing existing_variable_id with custom_value using CSS var() syntax works:

{
  "update_color_variable": {
    "variable_collection_id": "collection-6df1d4d5-d11b-a74a-fcf2-f32116c72fc1",
    "variable_id": "variable-089e73b1-7358-9339-d83c-b98312b53423",
    "value": { "custom_value": "var(--_primitives---colors--white)" }
  }
}

Response: {"status": "success"}. However this produces a "Custom value" (opaque CSS string) rather than a native alias, so Webflow loses the typed reference — the Designer UI shows it as custom-text rather than an alias pill, and the reference will silently break if the target variable's cssName ever changes.

Additional tests confirming the scope

Tried across six variants — all fail with existing_variable_id:

#	Source → Target	Same/Cross collection	Target creation method	Result
1	Background/secondary → Button Color/background	Same (Themes)	Relume-seeded	Error updating color variable...
2	Background/secondary → relume-variable--neutral-shade-1	Cross	Relume-seeded	Variable X not found
3	Background/secondary → variable-2e2a2b76-... (Brand/Sky 50)	Cross	MCP-created via create_color_variable	Variable X not found
4	Background/secondary → Overlay Color/primary	Same (Themes)	Relume-seeded, untouched, solid hsla() value	Error updating color variable...
5	Tag Color/border → Tag Color/text	Same (Themes)	Both MCP-updated with custom_value	Error updating color variable...
6	Background/secondary → relume-variable--neutral-white (ID confirmed valid by successful use in Background/primary's existing alias)	Cross	Relume-seeded	Variable X not found

Test 6 is the most compelling: the exact ID relume-variable--neutral-white is currently stored in Background/primary's value.id field and renders white correctly, but existing_variable_id with that same string returns "not found".

Impact

Any migration/automation that needs to create native cross-collection or same-collection aliases via MCP must fall back to custom_value + CSS var() syntax. This:

• Loses the typed alias relationship (target can be renamed and reference breaks silently)
• Renders as "Custom value" rather than an "Alias" in the Designer sidebar
• Prevents the alias from appearing in the target's "used by" back-references

For any serious design-token migration workflow, this effectively forces manual re-binding in the Designer UI as a post-processing step, defeating much of the MCP's value.

Suggested fix

The existing_variable_id lookup in update_color_variable appears to be scoped or filtered in a way that doesn't find variables it should. Suggested areas to investigate:

1. Whether the lookup is constrained by a stale in-memory collection index
2. Whether the lookup is filtering by variable_collection_id (the outer param, which should identify the source, not the target)
3. Whether there's a permission check keyed on creation-origin that rejects Relume-seeded / MCP-created variables as alias targets