8.1 What Is MCP

What Is MCP

MCP is a standard for connecting AI tools to external systems. For designers, it works like a plugin system — each MCP server you add gives Claude Code a new connection to a tool you already use.

MCP stands for Model Context Protocol. It is an open-source standard, maintained by Anthropic, that defines how AI applications talk to external tools and data sources. The official analogy: "Think of MCP like a USB-C port for AI applications." Every USB-C cable fits every USB-C port. Every MCP server fits every MCP-compatible client.

You do not need to understand the protocol itself. You need to know three things MCP servers can do:

The ecosystem is broad. MCP is supported by Claude Code, Claude Desktop, ChatGPT, Cursor, VS Code, JetBrains IDEs, and over forty other clients. The servers you set up for Claude Code also work in these other tools. One connection, many surfaces.

Transport types

MCP servers connect to Claude Code through one of three transport mechanisms:

For most design tool connections, you will use http for cloud services and stdio for local tools. The command to add a server is the same pattern regardless of transport.

Server scopes

When you add an MCP server, you choose where it lives:

For design teams, project scope is the sweet spot. Check .mcp.json into your repository and every team member gets the same Figma, Notion, and design token connections when they clone the project.

# List all configured servers
claude mcp list

# Check status inside a session
/mcp

8.2 Connecting Figma

Connecting Figma

Figma is the tool most designers want to connect first. The MCP approach lets Claude Code read your design files, extract tokens, pull component specs, and export frames — all without leaving the conversation.

Figma now documents an official Figma MCP path for Claude Code. The recommended route is the remote Figma MCP server, usually installed through Figma's Claude Code plugin and OAuth flow. Community servers still exist, and they can be useful for custom pipelines, but they should no longer be presented as the default path.

Adding a Figma MCP server

# Preferred setup path for most designers
claude plugin install figma@claude-plugins-official

# After install, open /plugin or /mcp and complete OAuth.

Use personal access tokens only when a documented workflow requires them. Prefer OAuth where the official plugin supports it, because scopes, revocation, and account approval are easier to manage.

Once connected, Claude Code gains access to Figma tools:

The Figma-to-code workflow

The canonical workflow looks like this:

"Implement the login screen from this Figma file: 
https://www.figma.com/file/abc123/Login-Flow

Use our design tokens from CLAUDE.md. Extract the colors 
and typography from the Figma styles first, then build the 
component."

Claude Code fetches the design data, reads your CLAUDE.md for conventions, and generates a working component. You iterate from there, the same way you refined prototypes in Chapter 3.

Using @ mentions for Figma resources

MCP servers can expose resources you reference with @ in your prompt:

"Analyze @figma:file://abc123 and create a React component 
for the hero section. Compare it to 
@figma:component://hero-v2 if that exists."

Resources appear in the autocomplete menu. You do not need to type the full URI — start typing @figma and select from the list.

8.3 Design Tool Integrations

Design Tool Integrations

MCP is tool-agnostic. Any design application with an API can be connected using the same pattern: find or build an MCP server, add it to Claude Code, use the tools in conversation.

Figma is the most common starting point, but the pattern generalizes. Sketch, Adobe XD, Storybook, design token platforms — if it has an API, it can have an MCP server.

Three tools in that table list "Build your own" as the MCP server path. If you use Sketch, Adobe XD, or Zeroheight and want a custom server, see section 8.6 for the build process. The MCP ecosystem is growing — a "build your own" entry today may have a community server next month.

The universal design token extraction pattern

Regardless of which design tool you use, the MCP server pattern for designers follows a consistent shape. Here is what a tool for extracting design data looks like in Python:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("design-tools")

@mcp.tool()
async def extract_colors(design_url: str) -> str:
    """Extract the color palette from a design file URL."""
    colors = await fetch_colors(design_url)
    return format_as_css_vars(colors)

@mcp.tool()
async def get_spacing_system(design_url: str) -> str:
    """Extract spacing values from a design file."""
    spacing = await analyze_spacing(design_url)
    return format_as_tailwind_config(spacing)

@mcp.tool()
async def compare_designs(url_a: str, url_b: str) -> str:
    """Compare two design files and highlight differences."""
    diff = await compute_diff(url_a, url_b)
    return format_diff(diff)

mcp.run(transport="stdio")

Three tools. Three capabilities. This is the pattern that works across every design tool integration — read data, extract structured information, compare versions. You build this once for your tool of choice and it works everywhere.

Adding any community server

The command is the same regardless of the design tool:

# Add any stdio-based design MCP server
claude mcp add --transport stdio sketch -- npx -y sketch-mcp-server

# Add Storybook integration
claude mcp add --transport stdio \
  --env STORYBOOK_URL=http://localhost:6006 \
  storybook -- npx -y storybook-mcp

If a server does not exist for your tool, you can build one. Section 8.6 covers that process.

8.4 Slack and Notion Workflows

Slack and Notion Workflows

Slack routes design tasks from team chat to working code. Notion gives Claude Code access to design briefs, specs, and documentation. Together, they turn conversations into implementations.

Slack integration

Claude Code has two distinct Slack features. Understanding the difference matters.

Claude Code in Slack is the feature most design teams will use day-to-day. You install the Claude app from the Slack Marketplace, connect your account, and invite @Claude to a channel. When you mention Claude with a coding task, it detects the intent, creates a Claude Code session on the web, and posts status updates back to the thread.

The session flow:

1. You @mention Claude with a request in a Slack channel
2. Claude detects coding intent
3. A new Claude Code session starts on claude.ai/code
4. Status updates appear in the Slack thread
5. On completion: summary + "View Session" and "Create PR" buttons

You choose a routing mode during setup. "Code only" sends every mention to a Claude Code session. "Code + Chat" routes intelligently — coding tasks to Code, writing and analysis tasks to Chat. For design teams, "Code + Chat" is the better choice because you will mix implementation requests with design feedback discussions.

Notion integration

Notion has an official, production-ready MCP server at https://mcp.notion.com/mcp. This is one of the most reliable integrations available — maintained by Notion itself, with OAuth authentication and enterprise controls.

# Add the official Notion MCP server
claude mcp add --transport http notion https://mcp.notion.com/mcp

After adding, authenticate inside a session:

/mcp

This opens the OAuth flow. Grant access to the workspaces and pages you want Claude Code to reach. Notion's admin controls let enterprise teams approve or block specific AI apps at the organization level.

Once connected, you can reference Notion pages directly:

"Read the design brief at @notion:page://design-brief-v3 
and build the component library based on the specifications. 
Cross-reference with our existing components in src/components/."

The combined workflow

This is where the hub model pays off. A single workflow can span three tools:

Designer posts Figma link in Slack channel
  → Claude Code reads the Slack message
  → Claude Code fetches the Figma design via MCP
  → Claude Code reads the Notion design brief for context
  → Claude Code implements the design
  → Claude Code creates a pull request
  → Claude Code updates the Notion task with implementation notes
  → Status posted back to the Slack thread

Each step uses a different MCP server. Claude Code orchestrates the sequence because it has access to all three tools simultaneously.

Channels for mobile design ops

Channels push events into a running Claude Code session. They are currently in research preview and support Telegram, Discord, and iMessage.

# Install a channel plugin
claude --channels plugin:telegram@claude-plugins-official
claude --channels plugin:discord@claude-plugins-official

8.5 Browser-Based Design Verification

Browser-Based Design Verification

The Chrome extension closes the feedback loop between code generation and visual output. It lets you see what Claude built, compare it to your design reference, and iterate without leaving the browser.

Every chapter in this book follows the same loop: describe your design, review the output, refine. But reviewing the output has always required a manual step. You generate code, open a browser, refresh, check it against your Figma file. That context switch breaks your flow. The Chrome extension removes it.

Think of it like the preview pane in Figma that shows your component in context. Except here, the "context" is a real browser rendering real code, and Claude can see what you see.

The visual verification workflow

The workflow is a three-step loop that replaces the old "generate, switch tabs, squint, switch back" routine:

The prompt that triggers this workflow:

"Open the login page in Chrome. Take a screenshot. Compare 
it to the design reference I pasted. List any visual 
differences and fix them."

Claude opens the page, captures what it sees, compares pixel-level details against your reference, and returns a structured list: spacing is off by 8px on the heading, the button color is #3B82F6 instead of #4F46E5, the border radius is 4px instead of 8px. Then it fixes each one.

Why this matters for designers

Designers judge output visually, not by reading code. The Chrome extension meets you where your judgment is strongest: looking at the rendered result. You do not need to parse CSS to know something is wrong. You can see it, describe what you see, and Claude adjusts.

This is the quality gate that was missing. Without it, you generate code, mentally render it in your head (or open a browser separately), and try to describe the visual gap in words. With it, Claude sees the same rendering you do. The feedback loop shrinks from minutes to seconds.

The comparison works best when your CLAUDE.md is loaded (Chapter 5). With design tokens defined, Claude can identify that "the blue is wrong" means the CSS is using #3B82F6 instead of your defined --color-primary: #4F46E5. The visual check plus the token reference gives Claude enough context to fix the problem in one pass.

8.6 Custom Servers and Connected Workspaces

Custom Servers and Connected Workspaces

When no existing MCP server fits your design tool, you build one. When you have multiple servers running, you orchestrate them into a connected workspace. This section covers both.

Think of building an MCP server like creating a Figma plugin — you define what data your tool can provide and what actions it can take, and Claude Code handles the rest. The MCP SDK gives you the structure. You fill in the design-specific logic.

The fastest path is asking Claude Code to scaffold the server for you:

/plugin install mcp-server-dev@claude-plugins-official
/mcp-server-dev:build-mcp-server

Claude asks about your use case and generates a working server with the right transport and tool definitions. This works for both local stdio servers and remote HTTP servers.

A design token MCP server in TypeScript

Here is a complete structural example — a server that exposes design-token and component tools. The fetch helpers are intentionally small placeholders because every design source has a different API contract:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "design-tokens",
  version: "1.0.0",
});

type TokenSet = Record<string, string | number>;

async function fetchAndExtractTokens(fileUrl: string): Promise<TokenSet> {
  // Replace with your Figma, token repository, or design-system API call.
  return { "color.primary": "#4F46E5", "radius.md": 8, "spacing.4": 16 };
}

function formatTokens(tokens: TokenSet, format: "css" | "scss" | "json" | "tailwind"): string {
  if (format === "json") return JSON.stringify(tokens, null, 2);
  return Object.entries(tokens)
    .map(([key, value]) => `--${key.replaceAll(".", "-")}: ${value};`)
    .join("\\n");
}

async function fetchComponent(fileUrl: string, componentName: string) {
  // Replace with your real component lookup.
  return { fileUrl, componentName, states: ["default", "hover", "disabled"] };
}

server.registerTool(
  "get_tokens",
  {
    description: "Get design tokens from a design file",
    inputSchema: {
      file_url: z.string().describe("URL to the design file"),
      format: z.enum(["css", "scss", "json", "tailwind"])
        .describe("Output format"),
    },
  },
  async ({ file_url, format }) => {
    const tokens = await fetchAndExtractTokens(file_url);
    const output = formatTokens(tokens, format);
    return { content: [{ type: "text", text: output }] };
  }
);

server.registerTool(
  "get_component",
  {
    description: "Get component specs from a design file",
    inputSchema: {
      file_url: z.string().describe("URL to the design file"),
      component_name: z.string().describe("Component name"),
    },
  },
  async ({ file_url, component_name }) => {
    const specs = await fetchComponent(file_url, component_name);
    return {
      content: [{ type: "text", text: JSON.stringify(specs, null, 2) }],
    };
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch(console.error);

Two tools. One fetches design tokens in the format your project needs. One fetches component specifications. Both return plain text that Claude Code reads and acts on. In design terms: the first tool is like exporting your Figma variables as CSS. The second is like reading a component's inspect panel.

Team configuration with .mcp.json

Once your custom server is built, add it to the project configuration alongside the other design tools:

{
  "mcpServers": {
    "figma": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "figma-mcp-server"],
      "env": {
        "FIGMA_ACCESS_TOKEN": "${FIGMA_TOKEN}"
      }
    },
    "notion": {
      "type": "http",
      "url": "https://mcp.notion.com/mcp"
    },
    "design-tokens": {
      "type": "stdio",
      "command": "node",
      "args": ["${CLAUDE_PROJECT_DIR}/tools/design-tokens-mcp/build/index.js"]
    },
    "storybook": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "storybook-mcp"],
      "env": {
        "STORYBOOK_URL": "http://localhost:6006"
      }
    }
  }
}

Check this file into version control only after a security review. Every team member who clones the repository gets the same MCP connection definitions, so each server should be trusted, documented, and scoped. Environment variables such as ${FIGMA_TOKEN} are set individually and should never be committed.

Enterprise managed configuration

For organizations, admins can deploy a fixed set of MCP servers to all machines:

Managed configuration ensures every designer on the team has the same Figma, Notion, and design system connections without manual setup. IT deploys the file, and the tools appear in everyone's Claude Code.

Choosing your connections

Not every team needs every integration. Here is a decision framework:

Start with one connection that solves a real pain point. For most designers, that is Figma — being able to say "implement this screen from Figma" and have Claude Code pull the design data directly is the most immediate workflow improvement. Notion is the second priority if your team stores specs there. Slack comes third for teams that route work through channels.

Claude Code as an MCP server

Claude Code itself can act as an MCP server. This means other AI tools — Claude Desktop, Cursor, or any MCP-compatible client — can use Claude Code's file editing, terminal access, and development capabilities through the same protocol.

{
  "mcpServers": {
    "claude-code": {
      "type": "stdio",
      "command": "claude",
      "args": ["mcp", "serve"]
    }
  }
}

Add this configuration to another MCP client, and that client gains the ability to read your project files, run commands, and edit code — all powered by Claude Code. For designers who prefer Claude Desktop's interface for exploration but need Claude Code's execution capabilities, this bridge gives you both.

The connected workspace is not about connecting everything. It is about connecting the right things — the tools where your design work already lives — so Claude Code operates on real data instead of pasted prompts.