Two ideas sit underneath almost every AI tool being built right now: MCP and Skills. They turn up constantly in release notes, Slack threads, and social feeds. Both are simpler than their names make them sound.

MCP gives your AI reach. Skills give it a recipe.

The rest of this article fills in the gaps: what each one means in practice, which to choose when, and how they work together. I’ll use Claude in the examples because it's what I’m most comfortable with day-to-day, but the core ideas apply no matter what client you run.

MCP: How Claude plugs into your tools

MCP stands for Model Context Protocol. It's a friendlier idea than its name suggests, and it begins to make sense as soon as you see the problem it was built to solve.

Before MCP, if you wanted Claude to talk to Figma, someone had to build a custom connector specifically for Claude. Want Cursor to talk to Figma? That meant a second custom connector from scratch. Every AI tool multiplied by every piece of software meant endless, fragile bridges. Most never got built, and the rest barely held together. So we did it the manual way: screenshot the frame, paste it into the chat, and describe what Claude was looking at.

MCP is the open standard that fixed that fragmentation. If you work in design systems, you already know this pattern. Remember when every screen had hardcoded hex values, until an updated brand palette forced everyone to hunt through 47 separate files? Design tokens fixed that by establishing a single reference point. MCP does the same thing for how AI tools talk to external software.

MCP changes what your AI can see, and how clearly. A teammate who only sees the screenshots you paste into Slack can comment on what's in the image, and no further. A teammate with your Figma file open can inspect the component architecture and read the variable collections directly. MCP is what hands Claude the file.

Under the hood, an MCP server is just a lightweight background process running alongside your app. It tells Claude what it's allowed to touch, like listing color variables in a collection or checking which components use a specific text style. Claude asks, "Can I read the variables in this file?". The MCP server handles permissions, fetches the data, and hands it back.

For example, imagine you want to know which layers in a component are using a raw hex instead of a color variable. Without MCP, you're clicking through frames one by one, or trialing plugins that get you part of the way. With the Figma MCP connected, you just ask. Claude walks the component, checks every fill and stroke, and hands back the list in seconds. When I ran it on a button set, it found fourteen, and pointed out they were all sitting on the hover and disabled states. Claude does the reasoning. MCP provides the reach.

Skills: Getting Claude to follow your playbook

Skills came later, but they tend to click faster, mostly because "skill" sounds like human language.

Anthropic introduced Skills in October 2025. Two months later the spec was published as an open standard, and tools like ChatGPT, Cursor, and Copilot adopted the format. A skill you write today can move between them, but how cleanly it moves will vary.

The problem Skills solve is repetition. If you want Claude to produce work in a specific way, like following your team’s component conventions or documentation structure, you used to have to re-explain that in every prompt, pack it into a long ‘custom instructions’ block, or create a project.

A skill fixes this by making your instructions contextual. You write your rules down once, save them as a skill, and Claude pulls them in whenever your prompt matches the job description at the top of the file.

You’ll have done versions of this before, for your teammates. When a new designer joins your team, you don’t re-explain component naming. You hand them the onboarding doc — the one you spent three days obsessively organizing — and it gets them up to speed quickly, without anyone walking them through it. A skill is that same reference doc, but written for AI.

Claude’s memory is the other half of that picture. Like a new colleague over their first few months, it picks up your role, how you like things worded, what you’re working on. The doc works differently, because you write it on purpose. It covers how the work gets done, and everyone gets the same copy. 

Technically speaking, a skill is just a folder containing a SKILL.md file alongside supporting checklists, reference docs, or examples. The description at the top of SKILL.md acts like component documentation: it tells the model when to pull the skill into context. If your prompt aligns with that description, Claude reads the file and follows your instructions.

Imagine that your team uses a strict six-part component documentation format: purpose, props, anti-patterns, composition, accessibility, and usage examples. Without a skill, you're constantly guiding Claude back to those six headings. With a skill in place, you ask Claude to document a component and it applies your structure without you steering.

Which one do you need?

The way I separate the two in my own head comes down to access versus instruction:

• Reach for MCP when Claude needs direct access to outside software (reading a Figma file, fetching Notion docs, or creating Asana tasks).

• Reach for a skill when you need Claude to perform a job following a specific standard (applying token naming rules, executing a review checklist, or structuring documentation).

They also layer on top of one another really nicely — a skill can direct Claude on how to use an MCP tool: "When auditing a component, use the Figma MCP to pull variant properties, then validate them against our deprecation checklist".

A few places to start

Most design system tooling built recently uses one, the other, or both... It’s amazing to see how much these workflows have changed over the last twelve months. 

If you start exploring, or playing with some of this, here are a few places to start:

AI clients that speak MCP:

• Claude: What I use most. Chat-based, so you don't need to be inside a code editor.

• Cursor: A code editor with native AI, and my go-to for design-to-code work. 

• VS Code with GitHub Copilot: Built-in MCP support if VS Code is already your daily workspace.

• Windsurf and Zed: Strong alternatives that support MCPs and, in many cases, Skills.

MCPs to try for design work:

• Figma MCP: Figma's official server and the default baseline for connecting Claude to your files.

• Figma Console MCP: TJ Pitre's community server at Southleft, and the one Joey wrote about earlier this year. It hooks into Figma's plugin API, allowing Claude to bulk-edit variables, audit component libraries, or refactor token structures in one pass.

• Storybook MCP: Bridges Claude to your coded component library so it generates UIs using your own components instead of guessing. 

• Mobbin MCP: Grants Claude access to over 600,000 real app screens for quick pattern research when you're stuck.

Skills to explore:

• Figma's /figma-use skill: Official skill enabling Claude to read and act on Figma files directly. 

• Anthropic's frontend-design skill: A sensible default for keeping AI-generated interfaces from looking like generic Tailwind templates. 

• Design System Ops: A skill pack I built for design systems practitioners covering token audits, deprecation plans, and drift detection. It handles the heavy maintenance work that's easy to fall behind on.

If you want one practical test: connect the Figma MCP to your client of choice, open a file you know well, and ask which layers are using a raw hex instead of a color variable.

For me, the more interesting part of exploring these tools has been working out what’s useful to ask for, and that’s where you start getting a feel for what Claude can actually see.

Skills come into their own later. My rough rule is three: the third time you catch yourself explaining the same preference to Claude, write it down as a skill.

What I hand over, and what I keep

One more thing before wrapping up, because it's probably the thing I care most about:

There's a version of this workflow where the end goal is to outsource as much systems work as humanly possible. You’ve probably seen this all over your X or LinkedIn feeds. But, realistically, that isn't how I use these tools. 

Every MCP call and custom skill spends compute and energy, and that footprint stays in the back of my mind. If an automated script saves a week of token auditing, that's a good trade. If it skips past the craft I enjoy, I'd rather do it myself.

I'm fully aware of the mild irony in building an entire pack of AI skills while telling you to guard your craft. But I'm protective of the nerdy parts of this job. The moment a messy token architecture finally clicks into place, the oddly soothing satisfaction of naming a variable just right, hand-building a component structure from scratch 😍. Those are the reasons I got into this work, and I'd like to keep them. AI can handle the mechanics. Saving room for the rest is still up to us.

Where that leaves you

Reach for MCP when Claude needs access to another tool. Reach for a skill when you want it to follow a consistent playbook. And keep the parts of the work you love for yourself.

The tools built on top of these will keep changing. Quickly. But the two foundational concepts discussed here are well-proven, making them the ideal starting point. Once you’ve worked with them enough, subsequent release notes will feel like variations on concepts you already understand, rather than something new to learn from scratch.

If you're figuring out how any of this fits into your team's workflow, the team here at Baseline would love to hear what you're trying out.

Thanks for reading. 👋 💛
— Murphy