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. TeMPOraL · 1790875110 · focus · HN ↗
  They're realizing what most product companies aren't yet (at least not openly): AI subsumes products.
  Most companies seem to still be in denial about it, and hope that if they add some more AI into their product, or do it just right, it will make sense. But it won't. AI is destined to sit on the outside, and products to be reduced into a bag of tools for AI to call.
  Taking away write access from AI tools outside their contractual control is an expected knee-jerk reaction, but it'll probably just hasten the product's slide into irrelevancy by ceding ground to competition (that will ultimately share the same fate, too, but is still in denial about it).
  1. amoorthy · 1790876691 · focus · HN ↗
    This is the crux of the issue. I think for infrequent use cases (question/answer) an MCP with tool-calls to some product makes sense.
    But for frequent use cases - something you do daily or weekly perhaps - then a native interface still has merit. i.e. I don't think AI subsumes the product in this case.
    TeMPOraL · 1790877206 · focus · HN ↗
    But it does. Even for daily use, you probably need only a fraction of the interface - but even if you need it all, the tool is usually only part of your work.
    You need other programs to do other parts of the same work - design in Figma, code in VS Code, collaboration in Google/Microsoft office suite, shitposting (er, well-being and psychological hygiene at work) in Slack, etc. AI sitting on the outside is able to operate all of them, combining their capabilities for you, to do what you want and how you want it. AI sitting inside a single product is limited only to the surface of that product, and is limited to capabilities the vendor wants.
    amoorthy · 1790877550 · focus · HN ↗
    That's a very good point. I wonder if AI within a product sometimes is substantially better than AI outside the product for a particular task. Because AI in the product is configured thoughtfully to do a great job at that task. So if quality is a requirement then AI in the product may still have merit?
    TeMPOraL · 1790880304 · focus · HN ↗
    That variant of "AI in the product" can still be viewed as a tool call for the general AI on the outside, and my point still stands. That AI / tool can be very much a commercial offering you pay for, but that's much less business than product vendors are used to today.
    While Figma could probably survive that way for some time, most software products can't, because they don't have anything special in them.
    --
    Fundamentally, a product is our industry's "unit of billable good/service". It's composed of a number of "operations" that are more or less closely related to each other, that someone grouped together into a larger whole with a User Interface, and slapped a brand on, so it can be sold.
    From user's POV, that UI is something standing in between the user and the problem they want solved. Sometimes it's what they need, other times - not quite. From vendor's POV, UI is the mechanism of control over what users can and cannot do, and a prime sales/marketing channel, because the audience is captive.
    Now, the AI sitting on the outside, operating on the functionality under UI, and composing it with functionality of other applications, gives users a superior meta-application, solving their own problem (and AI is not restricted to chat UI - there just hasn't been that much work done yet on ad-hoc, problem/user-specific UIs).
    For users, that's a win - the AI may not be perfect mode of interaction (can get close with custom UIs), but it does not obstruct them. For vendors, that's a disaster, because it destroys coherence of a product, reducing it to a bag of tool calls, with zero branding and no control/upsell surface.
    That's what I mean by AI subsuming products, and it being a mortal threat to most of the software companies today.
    amoorthy · 1790882692 · focus · HN ↗
    Makes sense what you say. Sounds like you've thought a lot about this. If you write a post somewhere I bet others on HN and beyond would fancy a discussion as it's very much a topical issue now.
    TeMPOraL · 1790884364 · focus · HN ↗
    I am in progress of reactivating my blog right now, might as well be a first post to write. I'll submit it to HN if and when I write it.
    These thoughts, I mostly refined over time on this very forum over the past year; some of those, in reverse-chronological order: <a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=ai%20subsume%20author%3ATeMPOraL&sort=byDate&type=comment" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    EDIT: in this very thread, you have an example of why AI on the outside beats AI on the inside: <a href="https://news.ycombinator.com/item?id=49923571">https://news.ycombinator.com/item?id=49923571.
    rixed · 1790914838 · focus · HN ↗
    Exactly my experience. Yet, I believe app will not only provide data but also some custom, short lived UI widgets in places where a more specific and consistent UX makes sense. But apps will definitively lose control over the navigation and even lose track of the user (they will identify and authorize only one : the harness; who sits behind will remain a mystery)
    I've written about this "UI to AI" pivot for my own Saas (cloudywithachanceoflatency.net). I believe it's a big win/win for every party.
    einsteinx2 · 1790977427 · focus · HN ↗
    > they will identify and authorize only one : the harness; who sits behind will remain a mystery
    This doesn’t sound right to me. To connect to the MCP server the user must authenticate. It’s not like all Claude users connect to Figma using the same account, the user connects using their Figma account. So the app still has a direct customer connection even if they lose the ability to control the UI. Unless you’re imagining some other way this would work that I’m not seeing.
    rixed · 1791001749 · focus · HN ↗
    I don't believe actual users will login. The LLM through their harness will, using an identity and password found in some shared vault. The app will still do authentication but no user management. Behind an access token there might be zero, one or several humans. Dystopian version: The allow-list for the oauth redir will become the new gatekeeper in a world without local compte, and the redir client the billed entity.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.