AI is moving from being a clever extra tab to becoming part of the working environment. That matters because the quality of an AI response is rarely just a model problem; it is usually a context problem. If the assistant cannot see the component, the variables, the frame or the constraints, it is doing the design equivalent of assembling IKEA furniture from a blurry photo.
That is why Figma’s Model Context Protocol (MCP) support is interesting. MCP is an open protocol for giving AI applications structured access to tools and context. Figma’s MCP server can provide a connected client with design context such as components, variables, layout data and selected frames; depending on the workflow, it can also help move work between code and canvas. Figma’s own guide is worth reading because the capabilities and access model are moving quickly.
What changes for designers
For years, using AI in design often meant copying a screenshot into a chat window, writing a heroic prompt, and hoping the model did not confidently invent a third navigation bar. MCP reduces that context gap. A connected tool can work from the actual structure of a file rather than a description of it.
That creates useful, practical possibilities:
Documentation: turn a selected component into a first draft of usage guidance, edge cases and accessibility checks.
Design-to-code alignment: give an agent the variables, components and layouts it needs to implement a frame with fewer guesses.
Faster critique: ask for a structured review of a flow, then let a human decide whether the advice is sensible.
Safer exploration: generate alternatives inside the constraints of an existing system, rather than starting from generic “modern SaaS dashboard” soup.
Context is a design-system problem
I learned the value of shared context while leading design-system work at ShipServ. The system gave designers and developers the same components, tokens and documentation; in the work described in my ShipServ design-system case study, that shared reference helped cut design time for new features by 75% and development time by 70%.
MCP does not replace that discipline. It makes it more important. An AI assistant can only reuse the rules it is given. If names are inconsistent, variants are mysterious and documentation is stored in someone’s head, the assistant will faithfully scale the confusion. Very efficient confusion is still confusion.
From prompt design to context design
Prompt craft still matters, but it is no longer the whole job. I now think about three layers:
Context: what file, component, selection, product rule and source of truth should the assistant use?
Task: what decision or artefact do I actually need?
Guardrails: what must not change, what needs review, and what counts as evidence?
A prompt such as “make this better” is still a coin toss. “Using this selected checkout form and its existing tokens, identify three accessibility risks; do not alter the layout; cite the relevant WCAG criteria” gives both the human and the model something usable to work with. My related post on prompt design as a UX skill goes deeper on that craft.
Keep a human in the loop
The temptation will be to automate everything that looks repeatable. Resist it. Use AI to accelerate drafts, surface gaps and reduce tedious translation between tools. Keep people accountable for product judgement, inclusive design, research interpretation and the awkward but important question: “Is this actually the right problem?”
For me, the exciting part of MCP is not that it makes AI feel magical. It is that it can make AI less magical and more useful: a collaborator that understands the product language we have deliberately created.
