Few acronyms have spread through the AI world as quickly as MCP, short for Model Context Protocol. Developers wire it into editors, design tools and chat apps so that an AI assistant can reach beyond its own text box. So it is worth noting when the co-founder of a major design software company, Dylan Field of Figma, says the protocol is not perfect. That is not an attack. It is the kind of candid assessment that usually comes from someone who has tried to build with a technology and found its edges.
What MCP is, in plain language
An AI model by itself can only work with the text it is given. To check a calendar, read a file, query a database or change a design, it needs a way to call outside tools. Before standards existed, every integration was custom: one connector for one app, with different rules each time. MCP is an open standard that describes a common way for an assistant to discover what a tool can do, ask it to do something and get a structured answer back. Think of it as a universal plug between assistants and the software they use.
Why designers and developers like it
- Reuse. Build a connector once and many assistants can use it.
- Discovery. A tool describes its own functions, so the assistant knows what is possible without hand-written instructions.
- Control. The software owner decides what is exposed, which is safer than letting a model scrape a screen.
For a design platform, that opens up useful workflows: an assistant could read the structure of a design, suggest changes or generate code from a layout, all while staying inside the permissions of the user’s account.
Where the protocol shows strain
Too many tools. Each connected tool adds descriptions to the model’s working memory. Connect dozens and the assistant spends much of its attention reading menus instead of solving your problem. Accuracy can drop when options pile up.
Security. A connector that can read files or send messages is a powerful capability. If a malicious document or web page contains hidden instructions, an assistant may follow them and use the connected tool in ways the user never intended. This family of attacks, often called prompt injection, remains hard to solve completely.
Authentication and permissions. Early versions left a lot to implementers. Questions such as who the assistant acts as, how access is revoked and how actions are logged were handled inconsistently, which frustrates enterprise buyers.
Reliability. A tool call is a conversation between two imperfect systems. Models can pass the wrong arguments or misinterpret results. Standards cannot fix a model’s mistakes, only make them easier to catch.
Why imperfect is not the same as failing
Almost every successful protocol started rough. The web’s early standards were clumsy, and email still carries decades of baggage. What matters is whether the standard is good enough to attract adoption and flexible enough to improve. MCP has momentum: vendors, open-source maintainers and cloud providers have published connectors, and the specification keeps changing in response to feedback. Criticism from builders is part of that process.
What could make it better
- Smarter discovery, so an assistant loads only the tools relevant to the current task.
- Clearer permission models, with per-action approval and audit trails.
- Stronger defenses against injected instructions, including labels that separate trusted from untrusted content.
- Better testing tools, so developers can measure how reliably an assistant uses their connector.
A concrete example from design work
Imagine asking an assistant to turn a rough mockup into a clean component library. With a good connector it can read the layers, names and spacing rules, propose consistent naming, and apply changes you approve. Without one, it only sees a screenshot and guesses. The difference is the reason designers care about the plumbing, and also why a flaw in that plumbing, such as the assistant misreading a layer or touching a file it should not, gets noticed fast. Teams that try this tend to report that the quality of the connector matters as much as the quality of the model.
Advice for teams adopting MCP
Start small. Connect a few tools that matter, and test them on real tasks before adding more. Give each connector the least access it needs, preferring read-only where possible. Require confirmation for actions that change data or spend money. And keep a human in the loop for anything irreversible. These are ordinary engineering habits, but they matter more when the caller is a language model.
The takeaway
When a founder calls a protocol imperfect, treat it as a signal to look at the trade-offs rather than a reason to avoid the technology. MCP solves a real problem, the messy integration of assistants with tools, and it does so well enough to be useful today. The remaining work is mostly about security, scale and polish, and the people building with it are best placed to say what needs fixing.
