[MCP] loadFontAsync fails for locally installed fonts

I also have this issue, which severely limits the usefulness of the MCP.
Claude seems to think it’s a limitation of how the Figma MCP server runs plugin code — that it “operates in a sandboxed environment that doesn't have the same local font access as Figma's main UI.” 
Would love a fix for this!

For anyone else with this issue, looks like the question has been addressed in this thread. There’s no fix as yet
 

Hi ​@Ronan M and ​@TenTen! I moved your replies over to this thread so we can keep the whole conversation in one place, that way you’ll get notified of any updates to this thread automatically.

I’m having the same problem!! This is definitely something people are NOT saying on LinkedIn when they talk about how amazing Claude + Figma is. 

Anyone find a work around other than manually correcting everything in Figma? 

I was able to use the Figma Console plugin and Figma Bridge Developer plugin to do this. You need both running while you use CoWork.

​@Junko3 here’s a little more info when I tried another angle with Claude today. (We) concluded this outcome with a failure still

We ran several tests trying to change an FA7 Pro icon via the Figma MCP's use_figma tool and hit the same wall every time.

What works fine:
Existing FA7 Pro text nodes render correctly in Figma because the FA Desktop App exposes the font to Figma's rendering engine.

What doesn't work:
Any attempt to write to an FA7 Pro text node fails — silently, no error thrown — because the Plugin API can't load the font. figma.listAvailableFontsAsync() only returns FA 5 & 6 Free. FA7 Pro is absent, meaning loadFontAsync() will error, and any operation that internally requires a font write (including setProperties on TEXT-type component properties) is silently dropped.

Approaches tested, all blocked:

1. Edit the TEXT node characters directly → requires loadFontAsync("Font Awesome 7 Pro") → not in the loadable font list → explicit error
2. setProperties on the nested v7-icon (pro) instance → silently does nothing — changing a TEXT-type prop still triggers an internal font write
3. Detach all parent instances, then edit the text node → same result, font still can't be loaded
4. Access via exposedInstances (the correct API for nested exposed props) → v7-icon (pro) is found and accessible, setProperties is called without error, but the icon doesn't change — same silent failure

Root cause:
The Plugin API runtime has a sandboxed font model. Licensed fonts distributed via the FA Desktop App are available to Figma's own rendering engine but are not surfaced to the Plugin API layer. This is a gap between what the Figma UI can do and what plugins/MCP can do.

What would fix it:
Figma exposing locally installed licensed fonts to the Plugin API runtime, or providing a dedicated API for icon component property swaps that bypasses the font-loading requirement.

Hey ​@megaroeny! 

Thank you for detailing what you discovered trying to use your Font Awesome font with the MCP; while expected when it comes to using a local font with the MCP, noting what you tested will be helpful for others who are not aware and try any of the tests you documented. Are the other fonts you listed local-only fonts, or were those uploaded to your organization?

Uploading fonts to your organization as mentioned by ​@Junko3  is another solution you can use in the meantime.

Can confirm, uploading fonts to my org has provided a workaround and allowed the MCP to use the local fonts I needed.

​@adamsmasher We're on the Professional plan, so we can't upload to our org. 🙁

Thanks for confirming that, ​@Dan Cheng! Glad to hear that works for you as a solution.

I’m sorry to hear that, ​@megaroeny. I can see how much more of a blocker this for you. I don’t have any specifics on this particular issue, but we are actively working on the MCP - hopefully this is something we can support in a future update!