Figma Co-Founder: MCP Is Not a Perfect Protocol, But Figma Will Embrace Multiple Standards

Figma's co-founder says MCP is not perfect; Figma will support multiple standards but will not expose all data.
Figma co-founder Dylan Field shared his views on the Model Context Protocol (MCP), saying that this open protocol introduced by Anthropic is not yet perfect, but that Figma will still support as many standards as possible rather than betting on a single protocol. At the same time, Figma explicitly stated that it will not expose all data to AI tools, reflecting a balance between open integration and data security. The article notes that design files often contain sensitive information such as product prototypes, brand assets, and user research, and that fully opening them would bring privacy risks, so access needs to be controlled through permission management, data anonymization, or selective exposure. This statement has reference value for AI integration across the design tool industry: while the AI ecosystem is still taking shape, remaining open but reserved can both improve efficiency and control risk.
Figma co-founder Dylan Field recently shared his views on the Model Context Protocol (MCP). He believes MCP is not a perfect protocol, but Figma still plans to support as many standards as possible while not exposing all of its data. This statement reveals a pragmatic strategy for design tools amid the wave of AI integration.
MCP's Limitations and Figma's Open Attitude
MCP is an open protocol introduced by Anthropic, designed to let AI models securely access external tools and data sources. It allows developers to build servers that expose various resources (such as databases, APIs, and file systems) to AI assistants, thereby extending the boundaries of model capabilities. However, Dylan Field stated bluntly that MCP is not yet perfect.
According to the original report, Field did not detail MCP's specific shortcomings, but his view reflects a reality: emerging protocols often have design deficiencies in their early stages, such as performance overhead, security models, or degree of standardization. Nevertheless, Figma's choice is to "support as many standards as possible" rather than betting on a single protocol. This multi-standard strategy means Figma wants to maintain flexibility and avoid being locked into a particular ecosystem.
Architectural note on "MCP servers"
MCP uses a client-server architecture, in which an "MCP server" is an adapter program that developers write for a particular data source or tool, responsible for packaging resources such as databases, file systems, and APIs into three standardized capability categories—"tools," "resources," and "prompts"—according to the MCP specification. The "MCP client" on the AI application side sends requests to the server at runtime, and the server performs the actual reads and writes as well as permission checks. The value of this design lies in decoupling: model vendors do not need to write separate adapter code for each external system, and tool vendors do not need to repeatedly develop plugins for each model. But the cost is an extra layer of inter-process communication and serialization overhead, and the server itself becomes a new trust boundary—who audits the implementation quality and data flows of third-party MCP servers currently lacks a unified answer, which is one of the common reasons the outside world remains cautious about the new protocol.
Industry context on "multi-standard support"
Beyond MCP, there are multiple paths for connecting tools with AI: model vendors' proprietary function calling formats, the plugin-style approach proposed by OpenAI, tool description specifications for agents, and custom integrations based directly on REST/GraphQL. These approaches are mutually incompatible in terms of authentication methods, granularity of capability description, and state management. For platform products like Figma, betting on only one protocol means ceding ecosystem voice to a single vendor; supporting multiple standards at the same time requires extra adaptation and maintenance costs. Therefore, "supporting as many standards as possible" is essentially a strategic choice to reduce lock-in risk and preserve bargaining space, rather than a purely technical preference.
Figma's Data Openness Boundary
Figma plans to support multiple standards, but explicitly states it "will not expose all data." This reflects a balance between openness and security. Design files often contain sensitive information, such as product prototypes, brand assets, and user research data. Exposing all data to AI models through protocols such as MCP could bring privacy and security risks.
Figma's position is this: while providing AI integration capabilities, it will exercise fine-grained control over data access. This may mean that Figma will use permission management, data anonymization, or selective exposure to ensure that only appropriate data can be accessed by AI tools. For enterprise users, this cautious attitude is crucial.
On the data sensitivity of design files and the principle of least privilege
Data in design tools is often more composite than in ordinary documents: a single Figma file may simultaneously contain unpublished product prototypes, visual proposals for trademarks not yet registered, raw screenshots from user interviews, and feature flows marked with internal code names. Once such information is leaked through AI tools, it constitutes not only a breach of trade secrets but may also trigger obligations to protect personal information in user research. The industry's common approach is the "principle of least privilege"—that is, each connected party should be able to access only the minimum dataset necessary to complete a specific task, rather than the entire workspace. Applied to protocols like MCP, feasible implementations include issuing access tokens at the file or project level, anonymizing text content before passing it to the model, and recording every external read in audit logs. Figma's statement that it "will not expose all data" most likely corresponds in engineering terms to this kind of fine-grained authorization and traceability mechanism, rather than a simple on-off openness.
Implications for AI Integration in Design Tools
Figma's statement has reference value for the entire design tool industry. As AI assistants are increasingly integrated into workflows, design tools need to find a reasonable way to collaborate with AI. Protocols such as MCP provide standardized interfaces, but tool vendors cannot blindly adopt them wholesale; instead, they should formulate strategies based on their own data characteristics and user needs.
From a broader perspective, Figma's multi-standard support strategy may become an industry trend. The AI ecosystem has not yet taken shape, and in addition to MCP, other protocols and integration approaches are competing. Tool vendors that remain open but reserved can both enjoy the efficiency gains brought by AI and control risks.
At present, Figma has not announced which standards it will specifically support or a timeline. But Dylan Field's statement has already sent a clear signal: Figma will not wait for a "perfect protocol" to appear, but will gradually improve its AI integration capabilities in practice. For designers and developers, this means that collaboration between Figma and AI tools will become closer in the future, but data security remains a prerequisite that cannot be ignored.
One-line Summary
Figma's co-founder says MCP is not perfect; Figma will support multiple standards but will not expose all data.
Paragraph Summary
Figma co-founder Dylan Field shared his views on the Model Context Protocol (MCP), saying that this open protocol introduced by Anthropic is not yet perfect, but that Figma will still support as many standards as possible rather than betting on a single protocol. At the same time, Figma explicitly stated that it will not expose all data to AI tools, reflecting a balance between open integration and data security. The article notes that design files often contain sensitive information such as product prototypes, brand assets, and user research, and that fully opening them would bring privacy risks, so access needs to be controlled through permission management, data anonymization, or selective exposure. This statement has reference value for AI integration across the design tool industry: while the AI ecosystem is still taking shape, remaining open but reserved can both improve efficiency and control risk.
Related articles

LLM Application Development: A High-Paying Career Guide for Ordinary People
LLM application development offers fresh graduates up to 35K/month, with SP offers reaching 600K. This article explains the core skills, how to break in, and how ordinary people can seize AI opportunities through learning by doing.

Say Goodbye to AI Influencer Faces: A Complete Guide to Creating Visual Assets for AI Comic Dramas from Scratch
Bilibili creator shares a full workflow for zero-basics AI comic drama visual assets: use Doubao Work skills with script-first, visual references, and real-person texture to escape AI influencer faces, then lock character and scene consistency with asset sheet layouts, weapon detail images, scene nine-grids, and cinematic color palettes.

The AI Production Pipeline Behind Great Videos: From Research to Agent Validation
AI video production isn't just a model race. This article breaks down a transferable four-step pipeline: researching professional workflows, organizing a skill checklist, configuring agents, and experimental validation—and explains how general-purpose LLMs like DeepSeek can replace paid tools to run the entire process.