Figma's Field Calls MCP Imperfect as Partners Pour In

Figma co-founder Dylan Field says the Model Context Protocol is "not a perfect protocol" even as his company adds 20 new MCP partners. The admission, made at Figma's first Config conference in India, exposes a quiet tension inside the standard that now connects most AI agents to outside tools: the companies publishing data through MCP do not all get the same deal out of it.

What happened

At Config India, Figma announced 20 new MCP partners, a list that includes Notion, Linear, Mistral, ClickUp, JetBrains' Junie, OpenCode, Meta Muse, Sarvam Agents, Amp and Dia. The message was openness: any agent, on any model, should be able to read a design file and act on it without a bespoke integration per vendor.

Field's own framing was more guarded. Asked about the protocol during a media briefing, he said he is "really excited about what we're doing in terms of opening up our ecosystem," then added: "I also think that MCP is not a perfect protocol. And I think that it is something that has tons of room for improvement. It is advantaged more to frontier labs."

It did not come out of nowhere. Days earlier, one of MCP's co-creators complained publicly that Figma was not supporting the open source tool Pi. Field replied on X that he found it interesting that Anthropic, the creator of MCP, "do not expose artifacts/other cloud resources created via MCP," arguing that "issues of asymmetric context sharing are ignored" while the debate gets framed as open versus closed. He later said Figma intends to support Pi.

Figma's stated reason for not opening everything is abuse risk: the more data it exposes through MCP, the higher the chance someone uses it badly, and the company still has to price in those users.

Why it matters

MCP was sold as neutral plumbing. Field's critique names the part nobody puts in the launch post: a protocol that standardizes access does not standardize what each side gives up. Frontier labs sit at the center of agent traffic, so they accumulate context from every partner that connects, while the partners that expose their data mostly receive requests. Whoever holds the agent surface captures the compounding value.

For builders it decides where integration work pays off. Shipping an MCP server makes your product usable inside someone else's agent, but it also turns your data into their retrieval layer. Exposing a design file or a CRM record is now a distribution decision, not a checkbox.

Builder impact

Treat MCP exposure as a product surface with a cost. Audit what you expose read-only versus writable and log who pulls it, because that abuse argument will land on your roadmap too. If one lab's agent is your main distribution channel, assume the context advantage runs one way until that lab exposes its own artifacts through the same protocol. Design for portability: an MCP server any client can call beats a bespoke integration with one assistant.