set_style applies the wrong class when a global class shares its name with a combo class (silently adds the combo's parent)

[aubynfs]

Summary

data_element_tool → set_style accepts only style_names: string[] and resolves each name via an internal lookup. When a global class and a combo class share the same name — which happens automatically whenever a global class is stacked as a second class anywhere on the site — the bare name resolves to the combo Style object. set_style then expands that combo to its full chain, silently re-introducing the parent class. There is no way to target the global class specifically.

This contradicts the underlying Webflow Designer API, which is explicitly built to disambiguate this case:

• getStyleByName(nameOrPath: string | Array<string>) — accepts a name or a parent→child path array specifically to distinguish a combo from a same-named global.
• setStyles(styles: Array<Style>) — takes Style objects (each with a unique id), not name strings.

So the disambiguation exists at the platform level; it's just not exposed through the MCP set_style surface.

Steps to reproduce

1. Create a global class bg-color-primary (e.g. it sets a background-color).
2. On any element, stack bg-color-primary as a second class on top of another class (e.g. section-hero). Webflow now stores a same-named combo Style object.
3. On a different element, call:

   set_style({ "id": "<element>", "style_names": ["bg-color-primary"], "return_element_info": true })

Expected

The element has exactly one class:

"styleNames": ["bg-color-primary"]

Actual

The element has two classes — the combo's full chain, with the parent silently re-added:

"styleNames": ["section-hero", "bg-color-primary"]

Confirming the collision

query_styles({ "name_path": ["bg-color-primary"], "include_properties": true }) returns two Style objects with the same name:

• one type: "global" (the real class, with its properties), and
• one type: "combo" (isComboClass: true, typically empty properties).

set_style resolves the bare name to the combo rather than the global.

Impact

This is not an edge case. Every global class that has ever been stacked as a second class produces a same-named combo, so it affects a large fraction of classes on any real Client-first / utility-class project. Agents can't reliably apply common utility classes (background, color, spacing, etc.), and the failure is silent — the element ends up with an unintended extra class rather than erroring.

There is also no safe client-side workaround: deleting or renaming the colliding combo breaks the other element that legitimately uses both classes together.

Suggested fix

Let set_style disambiguate, mirroring the underlying API. Any of:

1. Accept a style id per entry (resolve directly to that Style object); and/or
2. Accept a name-path array per entry (["bg-color-primary"] for the global vs ["section-hero", "bg-color-primary"] for the combo), passed through to getStyleByName(Array<string>); and/or
3. When a bare name is ambiguous, prefer the global (non-combo) Style object, since a combo can never be applied standalone anyway.

A minimal, backward-compatible version: allow each style_names entry to optionally be { "id": "..." } or { "path": ["...", "..."] } in addition to a plain string.

References

• getStyleByName — https://developers.webflow.com/designer/reference/get-style-by-name
• setStyles — https://developers.webflow.com/designer/reference/element-styles/setStyles
• Styles overview — https://developers.webflow.com/designer/reference/styles-overview