Figma restricts MCP access to whitelisted clients, excluding Pi
Thread
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
Figma restricts MCP access to whitelisted clients, excluding Pi
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
thdr · · focus · HN ↗
king_geedorah · · focus · HN ↗
qlte · · focus · HN ↗
Dylan16807 · · focus · HN ↗
dyllon · · focus · HN ↗
klardotsh · · focus · HN ↗
chpatrick · · focus · HN ↗
fidotron · · focus · HN ↗
For products for which this is true resorting to whitelisting clients simply accelerates your obsolescence by creating a temporary market for products that are MCP, and open agent, friendly.
fg137 · · focus · HN ↗
recursive · · focus · HN ↗
pjm331 · · focus · HN ↗
cavitnation · · focus · HN ↗
[dead]
alex7o · · focus · HN ↗
linuxftw · · focus · HN ↗
miguel-muniz · · focus · HN ↗
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/
cellularmitosis · · focus · HN ↗
The key to making it token efficient was allowing Claude to invent its own plaintext markup format for the lens output.
btown · · focus · HN ↗
<a href="https://developers.figma.com/docs/rest-api/file-endpoints/#get-file-nodes-endpoint" rel="nofollow">https://developers.figma.com/docs/rest-api/file-endpoints/#g...
<a href="https://developers.figma.com/docs/rest-api/file-node-types/" rel="nofollow">https://developers.figma.com/docs/rest-api/file-node-types/
Seems read-only, which means we're stuck with the MCP for updating Figma files... unless you've found a workaround there too?
joombaga · · focus · HN ↗
<a href="https://developers.figma.com/docs/plugins/" rel="nofollow">https://developers.figma.com/docs/plugins/
This is what I use. Load a little shim plugin and control it with whatever you want. I made the plugin poll an http server that listens for commands.
miguel-muniz · · focus · HN ↗
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.
oh_no · · focus · HN ↗
miguel-muniz · · focus · HN ↗
locallost · · focus · HN ↗
TeMPOraL · · focus · HN ↗
Neither of them, not yet. What will go away is the products currently used by these groups.
It's happening in software development, too. In the past 3 months, I used an IDE for maybe few hours total. 99% of my technical work is now easier and better done through agentic chat interface.
miguel-muniz · · focus · HN ↗
The way I have made peace with it in my mind is at the end of the day, I am the expert in UI/UX. There are many product teams I've joined that have operated without a designer and you can tell (bless their souls). Component libraries, templates, articles, video courses, and etc. have all existed throughout this time so it's not like they've been operating completely blind to design and UX. I don't think AI would be different. Sure it may raise the floor a little, but in the end someone needs to evaluate the output and hold responsibility for the UI/UX.
It was an uncomfortable idea to come to terms with though, I like many other designers spent a decade getting good at Figma. Figma and design almost felt intertwined for a moment, but designers have a long history of having their craft disrupted by new technology. Decades ago designers were cutting and pasting paper, then moved to digital publishing; and in product design we've gone through software such as Photoshop, Fireworks, Sketch, and Figma, just to name a few. Design has survived all this and will continue to survive in the future.
I think the same applies to the other disciplines. Sure I could have AI spin up a backend, but I don't really have the expertise to understand whether what it is doing is good or full of security vulnerabilities.
I don't know in the future if we will create a new path for product builders, individuals who are knowledgeable in all aspects of product management, software engineering, and product design. I also don't know if teams will have as much need for individuals with the efficiency gains from AI.
varispeed · · focus · HN ↗
timcobb · · focus · HN ↗
dataviz1000 · · focus · HN ↗
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 · · focus · HN ↗
rpdillon · · focus · HN ↗
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 · · focus · HN ↗
Basically anyone who understands systems will be fine and more and more important, even.
sergiotapia · · focus · HN ↗
evanjrowley · · focus · HN ↗
sergiotapia · · focus · HN ↗
jeffybefffy519 · · focus · HN ↗
14u2c · · focus · HN ↗
miguel-muniz · · focus · HN ↗
Code connect was supposed to bridge this gap, allowing users to define how Figma components should generate relevant code, but it only worked with React and they had some janky string based templating language for everything else. And of course, it meant someone would have to go through the effort of creating mappings for every component in your system. It's like writing a component twice.
Now people will just ask their AI to pull the frames from Figma through the remote MCP and have the AI implement it that way. But to that end, why not just have designers make a branch in the codebase and have them implement the UI? This is the question many of us have been asking ourselves lately.
They continue to iterate though. They've introduced Code Layers so real codebases can render on the canvas, but in infamous Figma fashion it only works with a limited set of React codebases. Figma Make (their Lovable, Bolt.new, Claude Design like product) can also pull in existing codebases, but again it is very limited in the types of code bases it can work on.
These limitations are all so exhuasting. It's just so much easier to use Claude Code or Codex to do what I need.
jeffybefffy519 · · focus · HN ↗
guluarte · · focus · HN ↗
miguel-muniz · · focus · HN ↗
[1] <a href="https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server" rel="nofollow">https://help.figma.com/hc/en-us/articles/32132100833559-Guid...
TeMPOraL · · focus · HN ↗
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).
amoorthy · · focus · HN ↗
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 · · focus · HN ↗
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, catering to your mental well-being) 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. AI sitting inside a single product is limited only to the surface of that product, and limited to capabilities the vendor wants.
amoorthy · · focus · HN ↗
TeMPOraL · · focus · HN ↗
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 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 · · focus · HN ↗
TeMPOraL · · focus · HN ↗
These thoughts, I mostly refined over time on this very forum over the past year; some of those, reverse chronologically: <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...
rixed · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
tomjen3 · · focus · HN ↗
I imagine I also want a specialized tool for, say, reviewing 3D models before printing them. And they would definitely like addresses to be shown in a navigable map.
But that type of interface already exist (and has been #killedbygoogle) - its Google Wave.
TeMPOraL · · focus · HN ↗
"I need an interface like ${this specific product} for my 3D scenes, but I also need to review each 3D model, which I normally do in ${that specialized tool}, and I'd love to have the two in one UI, well integrated, so I can ${description of your process}. Make it so."
Put that in Antigravity/Claude Code/Codex/whatever harness backed by a decent model, and good chances are, you'll have exactly what you wanted in less than half an hour.
miguel-muniz · · focus · HN ↗
reachableceo · · focus · HN ↗
All of my self hosted SAAS (redmine , gitea, discourse , vaultwaden , GLPI etc etc ) (even the cloudron pass if all runs on) is exactly that.
It’s beautiful! Of course as a self hoster that’s quite different then SAAS vendors who need to earn a profit I guess.
e3dd · · focus · HN ↗
Missing a lot of nuance.
It can both be true that a newcomer figures out an experience in which the tooling sits behind the scenes and has figured out various competitive advantages that may even result in monopoly.
Your posts carry an arrogant tint - check yourself.
evek · · focus · HN ↗
<a href="https://github.com/southleft/figma-console-mcp/tree/main" rel="nofollow">https://github.com/southleft/figma-console-mcp/tree/main
No affiliation, just found it useful.
radley · · focus · HN ↗
sumeetnaik · · focus · HN ↗
srulyrosenblat · · focus · HN ↗
<a href="https://www.oreilly.com/radar/mcp-in-practice/" rel="nofollow">https://www.oreilly.com/radar/mcp-in-practice/
MCP is only as useful as the servers people use are open.
spwa4 · · focus · HN ↗
The obvious play to "extract value" from that is to restrict access to bots and offer LLM integration themselves, for a fee.
thenewnewguy · · focus · HN ↗
adithyassekhar · · focus · HN ↗
Perz1val · · focus · HN ↗
spwa4 · · focus · HN ↗
sparkling · · focus · HN ↗
rirze · · focus · HN ↗
cosmotic · · focus · HN ↗
ihsw · · focus · HN ↗
[dead]
ChrisArchitect · · focus · HN ↗
You said no MCP
<a href="https://news.ycombinator.com/item?id=49906637">https://news.ycombinator.com/item?id=49906637
happyPersonR · · focus · HN ↗
mcbuilder · · focus · HN ↗
triyambakam · · focus · HN ↗
JimDabell · · focus · HN ↗
> on the figma mcp, we've had an email thread going on for 8 months trying to get it setup in opencode
> they seem very concerned with the labs competing with them
> finally got unblocked after i sent this email and it'll be rolled out in a week or so
The email:
> looking through the legal stuff the amount of things in there seems pretty crazy
> this is just an mcp server, there are thousands of them. we're not going to treat figma like its special
> we've been talking about this for this entire year, i don't think this makes much sense and i don't want my team burning more time on this
> once again, for a simple mcp server
— <a href="https://www.threads.com/@thdxr/post/Dd7LN-ylLQW" rel="nofollow">https://www.threads.com/@thdxr/post/Dd7LN-ylLQW
hadi77ir · · focus · HN ↗
Phemist · · focus · HN ↗
ihsw · · focus · HN ↗
[dead]
thehappypm · · focus · HN ↗
SkyPuncher · · focus · HN ↗
The security problem is two fold: (1) companies want control over where their data goes. Figma allowing any MCP creates problems (2) open redirects can create phishing issues. If your using Pi, you’re probably thinking of this. Most users aren’t.
For us, we decided to do an allowlist pattern because it was a reasonable tradeoff. The solution is allowing per-tenant client configuration, but that comes with its own set of issues (dev time, support, maintenance, etc). When nearly all of the money is flowing through a handful of well-known MCPs there’s little reason to out effort into supporting every MCP.
hparadiz · · focus · HN ↗
dbuxton · · focus · HN ↗
htrp · · focus · HN ↗
pjm331 · · focus · HN ↗
TeMPOraL · · focus · HN ↗
That's the age-old problem that's the root of this debacle, too. Both the companies and the users want control over a shared resource, and each side has a different opinion on where the border lies :).
(In practice, that's why my mind reads the phrase "OAuth redirect vulnerabilities" as a feature of a product, not a bug.
barefootsanders · · focus · HN ↗
[dead]
WhitneyLand · · focus · HN ↗
For my Figma needs, having Codex do computer use seems just as good as their mcp. I can tell it, “go download the assets for what I need and take a few screenshots for reference”.
miguel-muniz · · focus · HN ↗
I couldn't believe it when file annotations are only visible to users with design and dev seats. Like my PMs will never be able to read the annotations. I stopped using that feature entirely after that, and just stuck to pasting in FigJam sticky notes instead.
randbyte · · focus · HN ↗
RobertDeNiro · · focus · HN ↗
ig0r0 · · focus · HN ↗
Tade0 · · focus · HN ↗
It's really silly that this was the only means of blocking access. I expected them to have, I don't know, some sort of cryptographic signature or something.
An additional JWT with a long expiry time would even work here, anything.
TeMPOraL · · focus · HN ↗
zbowling · · focus · HN ↗
anandchowdhary · · focus · HN ↗
> Get started using the Slack MCP server by setting up a connection with an available partner
<a href="https://slack.com/help/articles/48855576908307-Guide-to-Model-Context-Protocol-in-Slack" rel="nofollow">https://slack.com/help/articles/48855576908307-Guide-to-Mode...
TeMPOraL · · focus · HN ↗
dbuxton · · focus · HN ↗
thefourthchime · · focus · HN ↗
allan_s · · focus · HN ↗
I created an opensource unofficial mcp/skill/cli here git@github.com:allan-simon/figma-kiwi-protocol.git
Its based on a reverse engineering of the kiwi protocol and it works for read/write , comments etc. and it does not require anything except a cookie session ( I usually automate this part by having a isolated chrome with CDP activated)
godwinson__4-8 · · focus · HN ↗
Better consumer choice, less companies stifling competition.
Tell your Congressperson! An easy way to frame it: why should I have to cross check Amazon or eBay or Walmart or w/e stupid janky frontend myself and find the best price/product? Why isn't it good for the economy if any agent harness can interface with such data as a consumer right?
The question is no different here. But most people don't know what figma is (it will probably not exist in 10 years anyway). However if we focus on the big abusers of platform economics, then the benefits we accrue from highlighting the tensions with consumers at those entities will simply flow downstream into the wider economy.
An economy that is more transparent is also a necessary precursor to robust UBI. When a company like Figma makes this move, the correct read should be they are buying into a playbook bent on depriving all of us of a more equitable future - one of the few optimistic possibilities for the highly contested future we are rapidly approaching.
xnx · · focus · HN ↗
jjcm · · focus · HN ↗
jdgoesmarching · · focus · HN ↗
miguel-muniz · · focus · HN ↗
Jcampuzano2 · · focus · HN ↗
I'm unfortunately inclined to think its the first because a reply as such from anybody who thought about this for even a minute would realize his reply has literally nothing to do with the original issue.
gitowiec · · focus · HN ↗
katzzzari · · focus · HN ↗
[dead]
thefourthchime · · focus · HN ↗
It did an amazing job.
thoughtpeddler · · focus · HN ↗
thefourthchime · · focus · HN ↗
tomaskafka · · focus · HN ↗
sneezychl · · focus · HN ↗
mococa · · focus · HN ↗
jedisct1 · · focus · HN ↗
Weird.
imagetic · · focus · HN ↗
vovkasm · · focus · HN ↗