Figma MCP Server: Cloud environment missing Arial breaks text style operations

Summary

The Figma MCP Server (Cloud) runs plugin code in a server-side environment that does not include Arial. Any plugin operation that depends on loading Arial — including figma.loadFontAsync({ family: 'Arial', style: 'Bold' }), text.setTextStyleIdAsync(arialBasedStyleId), or setting fontName to Arial — fails with:

The font "Arial Bold" could not be loaded. The syntax is figma.loadFontAsync({ family: "<family>", style: "<style>" }).

The same code executed via the Desktop Bridge (plugin running in the user’s local Figma Desktop) succeeds, because Arial is available as a system font on macOS and Windows.

This breaks parity between the two MCP execution environments. Code that’s valid against the Plugin API and runs correctly locally cannot be ported to Cloud MCP if it touches Arial.

Repro

1. Connect to the Figma MCP Server (Cloud) via any MCP client (e.g. Claude.ai, Claude Code, custom integration)
2. Run any of:

   await figma.loadFontAsync({ family: 'Arial', style: 'Bold' });
   

   const style = await figma.importStyleByKeyAsync('<key-of-arial-based-text-style>');
   await textNode.setTextStyleIdAsync(style.id);
   

   textNode.fontName = { family: 'Arial', style: 'Regular' };
   

3. Both fail with the unloaded font error.

To confirm the environment gap, run:

const fonts = await figma.listAvailableFontsAsync();
const arial = fonts.filter(f => /arial/i.test(f.fontName.family));
console.log(arial.length); // returns 0 on Cloud MCP

I verified this on a 7,739-font catalog returned from Cloud MCP. Zero Arial variants. Same query on Desktop Bridge returns Arial Regular, Bold, Italic, Bold Italic.

Why this matters

This blocks every workflow that involves email-template design files in Figma. Email rendering uses a tiny shared font set (Arial, Helvetica, Georgia, Times New Roman, Verdana, Tahoma, Courier New) because email clients can’t load web fonts. Any well-built email design system in Figma references one of these as its primary font family, and Arial is the most common fallback.

For our team specifically: we have a Lintel design system with an Email/* text style family bound to Arial. Cloud MCP cannot apply any of these styles, which forces every text-style operation through Desktop Bridge — a less stable, locally-scoped execution path that disconnects frequently. This negates much of the productivity gain of using Cloud MCP for design system work.

This is also likely an issue for any design system that uses other Microsoft system fonts (Calibri, Cambria, Segoe UI) or Apple system fonts (San Francisco) for similar reasons.

Proposed fix

Arial itself is Microsoft-licensed and can’t be shipped on a Linux server without licensing. The standard workaround in cloud rendering environments (LibreOffice, Google Docs export, Linux desktops generally) is Liberation Sans — an open-source, metrics-compatible Arial substitute released by Red Hat under the SIL Open Font License.

Two options that would resolve this:

1. Install Liberation Sans aliased to “Arial” in the Cloud MCP rendering environment. Plugin code would see Arialin the font catalog; loadFontAsync({ family: 'Arial', ... }) would succeed; rendered text would match Arial’s metrics. This is the simplest fix and matches what most Linux-based cloud document services do.
2. Install Liberation Sans under its own name and add a font-substitution map in Cloud MCP. When code requests Arial, transparently substitute. Same result, marginally more correctness for clients that inspect the actual font family.

Either approach resolves the parity issue. Option 1 is faster to ship.

Workaround (current)

Switch the workflow to Desktop Bridge for any operation that touches Arial. This works but disconnects frequently in long sessions, is locally scoped (no remote agent use), and doesn’t scale to team workflows where Cloud MCP is the only available transport.

File context (if helpful for repro): Splitero internal email design templates file with a Lintel-managed Email/* text style family. Happy to share access with a Figma engineer for diagnosis.