# MCP (Model Context Protocol) Explained for Designers

> MCP is an open standard that connects AI apps to tools and data. What a server exposes, local vs. remote servers and what to check before connecting one.

*Tags: ai, agents, protocols, tools*

---


> [!info] Quick Definition
> **MCP**, Model Context Protocol, is an open-source standard that defines how an AI application connects to external systems (files, databases, tools, workflows) using a common format. Its official documentation suggests thinking of it as a USB-C port for AI applications: one connector for many devices.


## What problem does it solve, and who is who?

Without a standard, every AI application needs its own integration with every service. Five applications and ten services mean fifty connections to maintain. With MCP, each service publishes a server once and each compatible application connects with the same protocol. The documentation sums it up as build once, integrate everywhere. Claude, ChatGPT, Visual Studio Code and Cursor are listed among the compatible clients.

For an [[what-is-an-ai-agent|AI agent]], MCP is one way to reach what it needs outside the model. The protocol only handles the exchange of context: it does not dictate how the application uses the model or manages that context.

The architecture has three participants:

- **Host:** the AI application that coordinates everything, such as Claude Code or Claude Desktop.
- **Client:** a component inside the host that keeps a dedicated connection to one server. The host creates one client per server.
- **Server:** the program that provides context and capabilities. It can run on your computer or on a provider's service.

An example from the documentation: Visual Studio Code is the host. If you connect it to the Sentry server and then to a local file server, it creates two clients, one per server.

## What can a server expose?

MCP defines three primitives that a server can offer:

| Primitive | What it is | Who controls it | Design example |
|---|---|---|---|
| Tools | Functions the model can invoke | The model | Adding a comment to a file |
| Resources | Read-only data that gives context | The application | Reading the variables of a design system |
| Prompts | Ready-to-use instruction templates | The user | "Review this screen with the accessibility guide" |

The practical difference is who decides. The model chooses when to call a tool, so that is where the risk sits: a tool can write to databases, modify files or call external APIs. The documentation says tools may require user consent before they run, and that applications can show approval dialogs or activity logs. The application requests a resource to give the model context. The user invokes a prompt explicitly, for example with a slash command.

The model reads the names and descriptions of the tools, just as in any [[tool-use|tool use]]. A server with clear names produces better calls.

## What changes between a local and a remote server?

"Local" and "remote" describe where the server runs, not what it does. A local server runs on your machine and uses the stdio transport (standard input and output); it usually serves a single client. A remote one runs on the service and uses Streamable HTTP (HTTP with optional streaming); it usually serves many clients. For authentication, MCP recommends OAuth.

| | Local (stdio) | Remote (Streamable HTTP) |
|---|---|---|
| Where it runs | Your computer | The provider's service |
| Installation | You do it | None, just connect |
| Main risk | Runs with your user's permissions | Depends on authorization and the provider |

Figma offers both. Its documentation recommends the remote server, which Figma hosts, does not need the desktop app and has more features; the desktop server runs inside the Figma app and is aimed at organization and enterprise needs. Writing to the canvas, meaning creating and editing frames, components and variables, only works with the remote server. For the full workflow, see [[figma-to-code-with-mcp|from Figma to code with MCP]] and [[mcp-servers-for-designers|useful MCP servers for designers]].

## What should you check before connecting a server?

The tools you use (a Figma file, a task board, a repository) can be exposed through MCP. An agent will be able to read what is in them and, if the server allows it, change it. Before connecting:

- **List of capabilities.** Read which tools it offers. What the server exposes is what the agent can do.
- **Read or write.** If there are tools that write, decide whether each call will ask for your approval. More on this in [[action-approval|action approval]] and [[agent-permissions-ux|permissions UX]].
- **Who publishes it.** MCP's security guide warns that a local server is a program you download and run, and that it runs with the same privileges as the client. A malicious server, or a startup command pasted from a tutorial without reading it, could run code on your machine. Check the full command before accepting it.
- **Minimum permissions.** The same guide recommends starting with the minimum scope and widening it only when needed. For your team, that means starting read-only.

You can reinforce the limit with [[sandboxing-and-permissions|sandboxing and permissions]], which restricts which files and networks the process can reach.

## When is MCP NOT the right choice?

- When you need a single custom function inside your own application. A simple local tool is more direct.
- When the service already has a native integration in the tool you use.
- When you cannot review what the server exposes or who maintains it.

## Example

Illustrative example: a product team connects Figma's remote server to Claude Code to generate code from a frame. Before connecting it, someone reads the list of tools and sees that some of them write to the canvas. They decide that every write call must ask for approval and that the agent works on a copy of the file, not the production one. That decision is made when configuring the connection, not in the prompt.

## What can you do tomorrow?

1. List the tools your team uses every day and check which ones have an official MCP server.
2. For each one, note whether access is read or write, whether the server is local or remote, and who can revoke it.
3. Start with a single read-only connection and use it for a week on a real task before adding another.

## Common mistakes

- Confusing MCP with an API. MCP is the protocol; a server usually wraps one or more APIs.
- Installing a third-party local server without reading the command it runs.
- Assuming the server has the same permissions as your account. It depends on how it is configured.
- Assuming the agent sees something the server does not expose.
- Connecting every write tool from the start "just in case".

## Sources

- [What is the Model Context Protocol, official MCP documentation](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Architecture overview, official MCP documentation](https://modelcontextprotocol.io/docs/learn/architecture)
- [Understanding MCP servers, official MCP documentation](https://modelcontextprotocol.io/docs/learn/server-concepts)
- [Security Best Practices, official MCP documentation](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [Figma MCP server, Figma documentation](https://developers.figma.com/docs/figma-mcp-server/)


---

Source: https://www.fernandoux.com/en/wiki/ai/mcp/