MCP get_design_context: Convert slash group separators to dashes in CSS custom property output

Context

With the Figma MCP server's `get_design_context` tool becoming a key part of design-to-code workflows, there's a friction point around how variable group separators are handled in CSS output.

Figma uses `/` to create variable groups (e.g., `blue/600` creates a `blue` folder containing `600`). This is great for organizing variables in the Figma UI. However, when the MCP generates code, the `/` is preserved literally in CSS custom property names: `--blue/600`.

The Problem

In Tailwind CSS — the default output framework for `get_design_context` — the `/` character is reserved as the opacity modifier delimiter:

bg-blue-500/75  →  background-color: rgb(59 130 246 / 0.75)

So when MCP output includes `bg-[var(--blue/600)]`, Tailwind's parser interprets `/600)]` as an opacity value, producing broken CSS.

The MCP works around this by escaping slashes as `\/`, but JavaScript consumes the backslash in normal strings. This forces every token reference into a `String.raw` template literal:

```jsx
// Current MCP output — unfamiliar pattern for most developers
<div className={String.raw`bg-[var(--blue\/600,#2563eb)]`} />
<div className={String.raw`rounded-[var(--radius\/full,999px)]`} />
```

vs. what it could be:

```jsx
// With dash conversion — clean, standard code
<div className="bg-[var(--blue-600,#2563eb)]" />
<div className="rounded-[var(--radius-full,999px)]" />
```

Why the MCP layer should handle this

The `/` is a Figma UI grouping mechanism, not a CSS naming convention. Every major design system converts group separators before CSS output:

No major design system uses `/` in CSS custom property names.

Suggestion

When `get_design_context` generates CSS code, convert `/` in variable names to `-`.

The `clientFrameworks` parameter already collects framework information — if Tailwind-aware conversion isn't feasible for all cases, it could be applied conditionally when `tailwind` is reported.

Alternatively, when a variable has no Code Syntax override set, defaulting to dash-separated names instead of raw slashes would be a minimal, non-breaking improvement.

Current workaround

Setting Code Syntax per variable (manually or via community plugins like Syntaxer) does work, but it's opt-in per variable and easy to miss when new variables are added.

Related threads

- Ability to specify format of Variables Code Syntax
- Ignore variable group names
- Variables Web Code Syntax Bugs