Figma Adds 20 MCP Partners as Dylan Field Warns the Protocol Favours Frontier Labs

Figma co-founder Dylan Field called the Model Context Protocol "not a perfect protocol" as the company announced 20 new MCP partners at its first Config conference in India, according to reporting published on October 20, 2026. TechCrunch

The new partners include Amp, ClickUp, Dia, Junie by JetBrains, Linear, Meta Muse, Mistral, Notion, OpenCode, and Sarvam Agents, among others. To use Figma's MCP features, you need an MCP client, an AI app that can call outside tools, listed in the Figma MCP catalog. MCP itself is a shared standard for letting AI assistants connect to other software.

Field said the protocol has "tons of room for improvement." He also said MCP is "advantaged more to frontier labs," meaning the large labs building the most capable AI models.

At the same time, the company offers a use_figma tool that lets MCP clients including Claude Code and Codex generate and change design assets tied to a design system. Figma The MCP server and use_figma tool can bring code onto the canvas or send designs back out as code. Figma

Figma states that MCP reduces errors and token usage, the amount of text and data an AI model must process, which affects cost and speed, to help teams move faster and more efficiently. Figma The Figma MCP server gives AI agents the design context they need to generate code from Figma files.

Field tied his caution directly to exposure. He said Figma does not want to be fully open because the more data exposed through MCP, the higher the chance of abuse.

He pointed to Anthropic, creators of the MCP standard, as following a similar constraint. Field wrote on X that Anthropic do not expose artifacts or other cloud resources created via MCP. He later added that Figma plans to support Pi.

In practical terms, the tension is architectural. MCP servers decide what tools, resources, and context to expose, and MCP clients decide how to invoke them. For a canvas that holds proprietary components, unpublished iterations, and linked code, every additional tool increases usefulness and risk together. Access control, scoping, and auditability become product decisions, not protocol guarantees.

The broader context here is useful for teams building on MCP. In my view, Field is describing a familiar standards moment. Early versions of a standard focus on getting connections working. Rules for permissions, safety, and cost control tend to arrive later, after misuse and bloated data use force the issue.

Looking at who feels that gap most, enterprise and mid-market developers are in a difficult position. Frontier labs can absorb large context windows, build their own internal tooling, and negotiate custom integrations. Smaller teams cannot. They work within public MCP servers, rate limits, and catalog constraints. If the protocol favours those who can work around it, adoption can look broad while the real advantage stays narrow.

Looking at what this means for design engineering specifically, Figma's approach is pragmatic. Keep the canvas open to agents through a curated catalog and a narrowly scoped tool. Hold back full openness until abuse models are better understood. It will slow some workflows. It also preserves trust in shared design systems, where a leaked component or incorrect AI edit can spread quickly into production code.

In my view, the long arc still points toward more agent access, not less. Structured design context is among the most useful inputs available to code generation models. The question is whether MCP grows into a protocol with clear scopes, resource-level permissions, and predictable token costs, or whether vendors add those controls on top in incompatible ways. Field's comments suggest Figma expects the second path unless the standard changes.