TL;DR
- MCP is a plug standard. It lets an AI application reach outside itself in a fixed, inspectable way, so a design file, a component library or a browser can be context instead of a screenshot.
- Three parties: the host you talk to, the client it opens per connection, and the server that exposes something. You configure hosts and servers. Clients are plumbing.
- Servers offer three things. Resources are data to read. Tools are actions to take. Prompts are canned instructions. Everything you will ever see an agent do through MCP is one of those.
- A screenshot shows what a design looks like. Structured context says what it is: which component, which variable, which layout rule. The agent can act on the second and can only guess at the first.
- Prompts, skills and MCP tools are three different layers. A prompt is what you want now. A skill is how you want it done every time. A tool is what the agent can reach. Confusing them is how teams end up pasting a design system into a chat window.
- Every tool call is a permission decision. Reading is cheap and safe. Writing is neither. Know which one the server you just connected can do.
Why a designer needs the vocabulary
You will not write an MCP server. You will sit in meetings where someone says the agent "has Figma access", and you need to know what that means: read access to selections, or write access to the canvas? Which tools, which file, which rate limit? You will decide whether a component library should be exposed as a resource or documented in a skill. You will be asked why the agent rebuilt a button instead of importing yours, and the answer is almost always in this vocabulary.
The Figma-specific version of all this is in Figma MCP for design work. This guide is the layer underneath it, and it applies to every server, not just Figma's.
The three parties
The Model Context Protocol describes a conversation between three roles.
| Role | What it is | Examples | Who configures it |
|---|---|---|---|
| Host | The application you talk to. It owns the model, the conversation and the permission prompts. | Claude Code, Cursor, Codex, Claude Desktop, VS Code | You, once, when you pick a tool |
| Client | A connection the host opens to one server. One per server. | Invisible in day-to-day use | Nobody. The host makes them. |
| Server | A program that exposes something the model cannot otherwise reach. | Figma's server, a Storybook server, a filesystem server, a database server | Whoever runs the thing being exposed. You add it to the host's config. |
Two practical consequences. The host decides what the model is allowed to do, so permission behaviour differs between Claude Code and Cursor even with the same server. And servers are independent of hosts, so a Figma server configured once works from any host that speaks the protocol. That is the point of a standard.
Servers run in one of two places. A local server is a process on your machine, started by the host, talking over standard input and output. A remote server is a URL you authenticate against, usually with OAuth. Figma offers both; the remote one at mcp.figma.com has the broader feature set. Remote servers are easier to share across a team and easier to revoke. Local servers can reach things on your machine that remote ones cannot, like the running Figma desktop app.
What a server can offer
A server exposes three kinds of thing. The protocol calls them primitives. You will see all three in the wild, often on the same server.
Resources: data to read
A resource is something the model can read: a file, a document, a query result, a Figma node's structure. Resources are addressed by URI, they can be listed, and the host decides which ones to put in front of the model. Reading a resource has no side effects. This is the safe half of MCP.
Design examples: the tokens JSON in a repo, the props of a Storybook component, the node tree of a Figma frame.
Tools: actions to take
A tool is a function the model can call with arguments and get a result back. get_design_context is a tool. So is use_figma, which writes to the canvas. So is run-story-tests in Storybook's server. Tools are how anything gets done, and they are where the risk lives, because a tool can read or it can change something and the protocol does not force servers to make the difference obvious.
The spec asks servers to annotate tools with hints such as read-only or destructive, and asks hosts to get user consent before running them. Hosts differ in how they do this. Some ask every time, some ask once per tool, some let you allow-list. Know which your host does before you connect a server that can write.
Prompts: instructions the server ships
A prompt is a reusable, parameterised instruction that the server provides and the user picks from a menu. Figma's server ships prompts for implementing a selection. They are the server author's opinion of how their server should be used. Useful as a starting point, and a good thing to read when a server is new to you, because they reveal the intended workflow.
The other direction
Servers can also ask things of the host. Three of these matter enough to know by name. Roots let the host tell a server which folders or scopes it may operate in. Sampling lets a server ask the host's model to complete something, so a server can be smart without shipping its own model. Elicitation lets a server ask the user a question mid-task, through the host's UI. When an agent stops to ask "which page in the file?", that may be elicitation from the server rather than the model deciding to be careful.
Why structured context beats a screenshot
Paste a screenshot of a card into a chat and ask for the code. The model sees pixels. It infers a border radius, guesses the font, estimates the padding, and produces a div with the values it thinks it saw. It looks close. It is wrong in every way that matters: it is not your component, it does not use your tokens, it will not respond the way the original does at a narrower width, and the next screenshot produces a slightly different card.
Now give the model the same card through a design server. It gets a structured tree: this is an instance of Card, its padding is the variable space/4, its background is surface/default, it is an Auto Layout column with a gap, and here is the production component that implements Card with these props. The model can import instead of rebuild, reference instead of guess, and the same selection produces the same result tomorrow.
| Question the agent has to answer | Screenshot | Structured context |
|---|---|---|
| Which component is this? | Guesses from appearance | Told by name and instance |
| Which colour token? | Samples a pixel, invents a hex | Reads the variable |
| What happens at 390px wide? | No information | Auto Layout intent, constraints |
| Which code implements it? | Nothing | Code Connect mapping, import path |
| Is this the same as the one on the last screen? | Cannot know | Same instance id |
| What is inside a collapsed state? | Invisible | Present in the tree |
The screenshot is not useless. It is the right tool for one job: checking the result. Every serious agent workflow ends by comparing the rendered output against the screenshot. It is the wrong tool for the beginning, because it destroys the information that makes reuse possible.
This is also why a well-structured design file matters more than the model. Structured context only carries what the file contains. A frame made of loose rectangles and a Group 5 gives the server nothing to say. Components, variables, semantic names and Auto Layout are the input format. Figma's own guidance on this is in the server guide, and the Figma guide here covers what to fix first.
Prompts, skills and tools are three layers
People use these words interchangeably. They are not the same thing, and the confusion has a cost: teams paste a design system into a prompt, or write a skill that tries to be a tool.
| Layer | What it is | Lifetime | Answers | Example |
|---|---|---|---|---|
| Prompt | What you want, right now | One message | "Build this?" | "Implement the selected frame using our Button" |
| Skill | How you want the work done, every time it comes up | Lives in a folder, loaded when relevant | "How?" | A file that says: read context, then metadata if truncated, then screenshot, import mapped components, never hardcode a token |
| MCP tool or resource | What the agent can reach or do | Lives in a server, available while connected | "With what?" | get_design_context, get_variable_defs, a tokens resource |
A prompt without a skill has to restate the process every time, and it will not. A skill without tools can only describe what it cannot see. A tool without a skill gets used the way the model happens to feel like using it today. The three compose: the tool provides the evidence, the skill provides the procedure, the prompt provides the intent.
Two tests for which layer something belongs in:
- Would you want it every time? Then it is a skill, not a prompt. "Never hardcode a value that has a token" is a skill line. "Make the hero taller" is a prompt.
- Does it have to be true right now, not remembered? Then it is a resource or a tool, not a skill. The current value of
accentlives in the token file, reached through a resource. A skill that saysaccent: #f4845fis a copy that will drift.
There is a fourth thing that sits under all three: rules files like CLAUDE.md or .cursor/rules, loaded every session, for facts about the project. Where the primitives live, which package manager, what never to touch. Facts go there. Taste goes in skills. Values go in resources. Intent goes in the prompt. What are skills goes deeper on the skill layer.
What "the agent has access to X" actually means
When someone says this, ask four questions. They are the same for every server.
- Read, write, or both? A server with only read tools can leak information but cannot change anything. A server with write tools can. Figma's
use_figmawrites to your canvas. A filesystem server can delete files. The answer changes how much you need to watch. - Which scope? A server usually reaches what the authenticated user can reach. Figma's remote server sees the files you can open. A filesystem server sees the roots it was given. Broad scope plus write tools is the combination to be careful with.
- Which host, and how does it ask? The same server behaves differently under a host that confirms every tool call and one that allow-lists. Find out which you are on.
- Whose server? Official servers from the vendor, or a community package? Community servers are real software with real bugs. One popular third-party Figma server had a command injection flaw exploitable through text in a Figma file. Treat a server like any other dependency: who maintains it, when was it last updated, what can it execute.
The protocol puts consent on the host, not the server. That is deliberate. But it means the safety of the whole setup depends on the host's consent UI being read rather than clicked through. If you find yourself approving tool calls without reading them, the setup has already failed, and the fix is fewer servers or a stricter host, not more dialogs.
A worked example, without Figma
To make the layers concrete with something other than a design file: an agent asked to add a dark-mode variant to a component.
- The rules file says the tokens live in
app/globals.cssunder@theme, and that dark mode is a.darkclass, not a media query. - The skill for colour says: derive dark mode by remapping which end of the scale feeds which role, never repaint by hand, and check contrast on every text and background pair after.
- A resource exposes the current token file, so the agent reads live values instead of remembering them.
- A tool runs the contrast sweep and returns failures.
- The prompt is one line: "Add a dark variant to the Card and make it pass."
Remove any one layer and you can predict the failure. No rules file: the agent adds a prefers-color-scheme query. No skill: it hand-picks a dark hex per element. No resource: it uses last month's accent. No tool: it reports "looks fine" without measuring. No prompt: nothing happens. That is what the layers are for.
Checklist: before you connect a server
- I know whether it is local or remote, and what it authenticates as
- I have read its tool list and marked which tools write
- I know what scope it reaches: which files, folders, accounts
- I know how my host asks for consent, and whether anything is allow-listed
- The server is official, or I have looked at who maintains the package and when it last changed
- There is a skill or rules file telling the agent when and how to use it, so the tool is not used on vibes
- I have run it once on something disposable and read the tool calls it made
Checklist: is this a prompt, a skill, a resource or a rule?
- Wanted every time the task comes up: skill
- Must be true right now, not remembered: resource or tool
- A fact about this project that never changes within a session: rules file
- What I want in this one message: prompt
- A value the code already declares: none of the above, link to the code
Where this leads
Once the vocabulary is in place, the Figma guide reads as an application of it: Figma's server offers read tools for context, metadata, screenshots and variables, write tools for code to canvas and native edits, and ships prompts for implementation. The skill layer is the implement, drift-check and roundtrip skills. The rules layer is your project's CLAUDE.md. The prompt is the ticket.
The pattern repeats for every server you will meet: Storybook exposes components and tests, a database server exposes tables, a browser server exposes a page. Same three parties, same three primitives, same four questions before you connect it.
Sources
Recommended Tools
Was this article helpful?