For a protocol barely two years old, the Model Context Protocol has had an unusual career: it went from a specification to an assumption in under eighteen months. Figma co-founder Dylan Field's assessment, reported by TechCrunch on 20 October — that MCP is not a perfect protocol — is worth taking seriously not because it is contrarian, but because it comes from someone who has had to ship against it.
What MCP does, and why it won
MCP standardises how an AI application exposes tools and data to a model. A server declares its capabilities, a client connects, the model calls tools. The appeal was structural: before it, every AI product that wanted to read your files, query your database or drive your design tool built a bespoke integration, and every integration was maintained twice — once by the tool, once by the assistant. One protocol instead of N-times-M connectors.
The cost of that success is that a specification which became the default so quickly had little time to harden against its own mistakes. What is surfacing now are engineering complaints, and they are mostly about cost and trust rather than capability.
Four places it rubs
**Context is not free.** Tool definitions consume tokens. A server exposing twenty tools can spend thousands of tokens describing itself before the model has read a single word of the user's request. In an agentic loop running many turns, that tax compounds. Protocol design that treats tool schemas as weightless looks different when you are billed per token per turn.
**Authentication is the one with security consequences.** MCP servers frequently hold credentials to real systems. The protocol's auth story was revised after early deployments exposed confused-deputy problems: a server that can act on a user's behalf needs to know precisely whose behalf, and token scoping across a chain of client, model and server is easy to get subtly wrong. A permission model that works in a demo is not the same thing as one that works when a thousand users share a server.
**State and versioning.** Sessions, capability negotiation and the behaviour of schema changes are the parts of a specification nobody reads until they break. Ecosystems that grow fast grow unevenly: a server author tests against two or three clients, and the rest of the market discovers the gaps.
**Client fragmentation.** A standard whose reference implementations are the real spec drifts. When different clients implement different subsets, "supports MCP" becomes a claim you have to verify per client rather than a property you can rely on.
Why Figma, of all companies, is saying it
Design data is the pathological case for this model. A design file is large, highly structured and high-fidelity — putting the whole thing in context is simultaneously expensive and lossy. Precisely where context cost and output fidelity are both under pressure, a protocol's weaknesses show up first. Figma has shipped MCP support; living with it is a different exercise from demoing it.
That is also why the remark should not be read as a rejection. It is the normal sound of a standard maturing: the first wave of enthusiasm is over, the second wave is people paying the bills.
What a better protocol looks like
The constructive answer to the criticism is unglamorous, and most of it is already known.
Tools should be discoverable rather than fully declared — a short description that fetches detail on demand instead of twenty schemas up front. Capabilities should be negotiated so client and server agree on an intersection rather than assuming one. Tokens should be narrowly scoped and bound to a purpose, not to a session. And reads should be separated from writes: a server permitted to query a database should not carry the same authority as one permitted to alter it.
None of this is impossible, and much of it is in progress. The open question is governance: can MCP's stewardship make breaking-ish changes while the ecosystem is still young enough to absorb them? That window is closing now.
The read
The sharpest criticism of a standard rarely comes from its opponents. It comes from the users who took it seriously. A design-tool founder saying publicly that the protocol is not perfect is not evidence that MCP is failing — it is evidence that it has become important enough to criticise.
Two things to watch in the coming months: whether auth and permission models get standardised beyond the spec, and whether the major clients start agreeing on the same subset. Until both happen, "MCP-compatible" remains a claim to check rather than a property to build on.
