Thread

Figma restricts MCP access to whitelisted clients, excluding Pi

187 points · 106 comments · thdr

miguel-muniz · 1790869419 · focus · HN ↗
For context: Figma has two MCPs. The local "dev" MCP that works through the Desktop app, and the remote MCP that requires a connection to Figma. Companies need to be whitelisted to use the remote MCP, which is the only one that allows agents edit access to Figma documents.
I only found out about Figma's limitation when I was trying to add the remote MCP server to GitHub Copilot Desktop and kept running into errors. Turns out they whitelisted GitHub Copilot CLI but not the Desktop app and had put a pause on enabling any more vendors. Eventually someone (not sure which side) got it working.
Kind of strange to limit edit access only to the Remote MCP when their competitors like Pen[1] and Paper[2] allow any local agent to edit.
[1] <a href="https://www.pen.dev/" rel="nofollow">https://www.pen.dev/
[2] <a href="https://paper.design/" rel="nofollow">https://paper.design/
1. miguel-muniz · 1790872749 · focus · HN ↗
  To speak more broadly, Figma is in a really tough spot right now. I see more and more designers in my circle saying they are skipping design tools entirely to prototype in code or ship directly in their product's code base. Honestly I find myself doing the same.
  Figma's main value used to be in providing designers a canvas to iterate and explore ideas since the majority of designers did not code, but AI has completely changed that.
  I fear Figma's reluctance to integrate with all the popular AI tools might actually accelerate their decline. AI provides so much value, that I would rather base my software purchasing decisions around what is compatible with my AI of choice rather than pick an AI that is compatible with Figma.
  1. dataviz1000 · 1790877444 · focus · HN ↗
    Everyone is in a really tough spot.
    The AI companies focused most their effort on writing software and continue to do so. Software, SaaS, and software engineers are the first to be disrupted.
    > but AI has completely changed that.
    Exactly. However, it is because AI is focused on solving writing software first which is the step to solving everything else.
    bmitc · 1790911948 · focus · HN ↗
    From what I can see, it's everyone else who is in trouble. Software engineers have years of skills of corralling complexity, navigating requirements, etc., and all of these things matter more and more in the age of LLM tooling. It seems to me that software engineers will be taking others' roles, because if you know how to wrangle LLMs, which is something software engineers do know how to do, then you can all of the sudden take over other domains.
    rpdillon · 1790940107 · focus · HN ↗
    This is closer to the reality I'm seeing. Software engineers are well positioned to understand and deploy LLMs to solve problems, even in adjacent domains. One of the engineers I work with gave a short presentation yesterday. It was quite simple. He'd just taken a series of screenshots from our product and put it into a Claude desktop session with some pretty significant prompt explaining how the screenshots related to a particular user flow and what the desired changes we were thinking about making were.
    Took about 45 minutes and produced a working mock that we could then play with and see if the UX felt right. It was surprisingly high fidelity, and while the code was entirely throw away, it helped a room full of people make decisions about how we wanted the tool to feel within the first couple of hours of thinking about the project. Designers bring a wealth of UX thinking to that discussion, but the process of creating the mock was done entirely by engineering.
    bmitc · 1790959606 · focus · HN ↗
    I think UX designers are also well-positioned, especially those that are more technical and can use LLMs.
    Basically anyone who understands systems will be fine and more and more important, even.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.