There’s a quiet tension in how we build tools for designers and engineers. Some tools try to stay out of your way. They hand you raw access and let you decide what to do with it. Others take a strong position. They know exactly who you are and what you are trying to do, and they give you a shortcut. Both approaches are right. They are right for different reasons.
The native Figma MCP and the Figma Console MCP sit on opposite ends of that spectrum. I have been thinking about how to get the strengths of one without giving up the other, and skills turned out to be the answer.
Two philosophies
The native Figma MCP is open by design. It connects an AI agent to the Figma canvas and mostly refuses to tell you how to work. Read a file, move a node, build a component, inspect variables. It exposes the surface and steps back. And when it wants to extend itself, it leans on skills rather than baking in opinions. I love that direction. An unopinionated platform ages well, because it doesn’t assume your workflow.
The Figma Console MCP made the opposite bet, and made it on purpose. It is opinionated toward design systems. Over a hundred tools, many built to answer the specific questions design systems practitioners actually ask. How healthy is this token set? Does this component have a focus state? Can I get these variables out as Tailwind? It is less “here is the canvas” and more “here is everything you need for this job.”
Neither stance is better. But if you live in design systems work, you feel the distance between them. The native MCP is everywhere and endlessly flexible. The Console MCP is deep but separate.
Skills are the bridge
Here is the realization that started this. A skill is portable expertise. It is a folder of instructions and scripts that teaches an agent how to do a specific job well, and it is not tied to a product. It travels.
That means the opinionated capability living inside the Console MCP does not have to stay there. You can lift the part that matters, the actual know-how, and drop it onto the open platform. The native MCP keeps being open and flexible. It just picks up a set of design-systems instincts it did not have before.
Said plainly: capability should not be locked to one tool. If something does real work, the goal is not to argue about where it lives. It is to make it available to the people who need it.
What I built
I went through the Console MCP’s tools and pulled the 22 that get the most mileage. Token export and import. Accessibility audits on the design side and the code side. Design-system linting. Component documentation. Design/code parity. Component-set analysis. The work that comes up again and again when you are standing up a new system or salvaging an old one.
Then I did the less satisfying part. I left things out. Anything that overlaps with what the native MCP already handles well did not make the cut. No duplicates, no filler. The curation is most of the value here. A pile of a hundred tools is not helpful. A tight set of 22 that each earn their place is.
It is a public repo, with install instructions for Claude Code, Claude Desktop, and other platforms in the README.
→ https://github.com/southleft/figma-console-mcp-skills
How it works
Under the hood, most of these skills run through the native MCP’s use_figma tool, which executes against the Figma Plugin API. That detail matters more than it sounds. Because it reads through the Plugin API rather than Figma’s Enterprise-only Variables REST API, something like token export works on any plan, not just Enterprise. It also resolves alias references and multiple modes, which the simpler variable reads tend to drop.
In practice, most of the set runs anywhere the Figma connector is live, including plain Claude chat. A smaller group that depends on Figma’s REST API, the version history, changelog, blame, and comments skills, needs Claude Code and a Figma token. The README is clear about which is which, so you are never guessing.
Two examples make the range concrete.
A token export reads every local variable in your file, resolves the references and modes, and emits the format you ask for: CSS custom properties, Tailwind, SCSS, TypeScript, or DTCG JSON. If you have ever wired up Style Dictionary by hand and written your own conversion functions, this folds a lot of that into a single request. In the attached video, I ran it against a real system and it pulled 312 variables across two tiers, primitives and semantic tokens, with the light and dark modes intact.
The accessibility audit goes the other direction, narrow and deep. Point it at one component or component set and it returns a weighted scorecard: variant coverage, focus indicator quality, non-color state differentiation, target size, annotation completeness, and color-blind simulation across three types of color vision deficiency. Each category gets a score, and the output is a sorted list of fixes with the relevant WCAG criteria named. In the demo I ran it on a badge, it came back with a 79, and it told me exactly what to change to raise it.
The point
This was never about which MCP wins. The native Figma MCP is excellent at being open. The Console MCP is excellent at being deep. Skills are how you stop choosing between the two.
If you work in design systems and you already use the native Figma MCP, you can have the depth without leaving the tool you like. And if you build tools yourself, the same pattern is sitting right there for you. The capability you are proud of does not have to stay locked inside your product. You can package it as a skill and hand it to everyone.
Take what’s useful, leave the rest. They’re all yours!
