Working with agents · 23 June 2026 · 4 min

MCP for designers: what it actually is

A plain explanation of the protocol that lets your agent read your tools — and why design context belongs in it.

If you work near engineers you have heard MCP mentioned roughly weekly for a year, usually in a sentence that assumes you already know what it is. Here is the version that does not.

The plain version

The Model Context Protocol is a small standard for letting an AI agent read from and write to something outside its chat window.

A server exposes a handful of named capabilities — get_canvas, search_issues, read_file. The client is the agent: Claude Code, Cursor, Codex, whatever you use. When the agent decides it needs that information, it calls the capability by name and gets structured data back.

That is genuinely the whole idea. The reason it merited a standard is the combinatorial one: before it, every agent needed a bespoke integration with every tool. MCP makes that an N + M problem instead of an N × M one, which is why it spread quickly after Anthropic published it. The specification and SDKs are open, and there is now a server for most things engineers touch daily.

Two things worth knowing, because they come up in security review:

The agent decides when to call. You do not invoke a tool; the model does, when the task appears to need it. This is why the capability's name and description matter — they are what the model reasons over.
A server can be read-only. Nothing about the protocol requires write access, and a well-built server for reference material should not have it.

Where design context sits today

For engineers this has meant repositories, issue trackers, CI and databases. The agent reads the codebase because reading the codebase is a solved problem.

Design context has stayed stubbornly outside. In practice it lives in:

A prompt, retyped slightly differently every session
A screenshot pasted into chat
A Figma file the agent cannot open
Someone's memory of what was agreed in a meeting

So the agent writes code against a current, precise view of the system's logic and a vague, stale view of what it should look like. Then everyone is surprised the output looks generic — which is the mechanism behind why every vibe-coded app looks the same.

There is no good reason for that

Fonts, colours, radii, motion durations, logomarks, voice rules, personas — these are structured data. They have names and values. They are exactly the shape of thing a tool call returns well.

The awkwardness has been sociological rather than technical. Design decisions live in tools built for humans looking at them, so the machine-readable version was never anybody's job. Design tokens got partway there and stopped at the values: a token file gives an agent #E8511E but not "primary action only, never body text" — and as building a colour palette you can defend argues, the rule is the part that generalises.

Exposed over MCP, the whole record becomes something the agent consults the way it consults the codebase. Not pasted. Not summarised. Read, at the moment of use, in its current state.

What changes in practice

You connect once per repository. From then on, prompts are written against your current taste rather than your memory of it.

Concretely, the difference is this. "Build the pricing page" with no context produces a competent generic pricing page. The same four words with a canvas connected produce one that uses your display face at your tracking, your accent on the buttons and nowhere else, and copy addressed to the person on your persona card — because the agent called get_canvas before it wrote a line.

The mechanics take about a minute: one block of config per client. The docs have the quickstart, tools and resources lists what an agent can actually call, and there are setup guides for Claude Code, Cursor and the rest.

A few properties worth insisting on in any server that holds your design decisions, and which moodspec's endpoint enforces: it is read-only, so a leaked token exposes taste rather than write access; the token is scoped to one canvas rather than an account, so revoking it affects one repository; and it is rate-limited per token. The tokens and limits page is specific about all three.

The short version

MCP is not a design tool and was not built with designers in mind. It is a way for an agent to fetch structured data at the moment it needs it — and design decisions have always been structured data that nobody bothered to expose.

Getting them exposed is the practical half of teaching an agent your taste. The other half is deciding what your taste is, which no protocol will do for you.