Teaching AI agents your design system with MCP

Ask a coding agent for a Save button and it will write one in seconds. Ask it to use Nexera UI and it will still write one in seconds, with props that look plausible and do not exist. This post explains why that happens, and how a Model Context Protocol (MCP) server for Nexera would let an agent look things up and check its answer before it shows you code.

Why agents guess component APIs

A language model learns component libraries from the code it saw during training. Most of that code uses a handful of popular libraries, so the model has strong habits: onClick for buttons, disabled for disabled states, size="medium", type="primary". When you ask for a Nexera component, the model fills the gaps with those habits.

Nexera follows React Aria conventions, so the habits are often wrong. A Nexera Button takes onPress, isDisabled and isLoading. Its size is sm, md or lg, and its variant is primary, secondary, ghost or destructive. An icon-only button is a separate component, IconButton, and TypeScript refuses it without an aria-label or aria-labelledby.

The same goes for styling. An agent that has never seen our tokens reaches for bg-blue-600 or a hex value. In Nexera that colour should be bg-brand-primary, which follows the theme in light mode, dark mode and any brand you generate with createTheme(). A hard-coded blue breaks all three.

None of these mistakes is exotic. They compile under a loose config, pass a quick glance in review and fail later: a click handler that never fires, a button with no accessible name, a colour that ignores dark mode.

What an MCP server changes

MCP is an open protocol that lets an AI client call tools provided by a local or remote server. Claude Code, Cursor and other clients already speak it. A server exposes named tools with typed inputs, and the agent decides when to call them.

For a component library, that means the agent can stop relying on memory. Before writing JSX, it can ask the server what Button accepts in the version you have installed. Before picking a colour, it can ask which tokens exist. Before answering, it can hand its JSX back to the server and ask what is wrong with it.

The data an MCP server needs already exists in the repository. Props carry TSDoc comments with their defaults, most of them naming the Figma property they map to, and the docs site generates a registry from the source with each component's name, category, status and props, including types and defaults. The tokens package exports a typed object of every token, generated from the Figma variables.

The planned tools

We plan five tools. Names and shapes may change before release.

• search_components takes a plain-language query ("date range", "confirm before delete") and returns matching components with a one-line summary each.
• get_component returns one component's props with types, defaults and descriptions, its accessible-name rules and a short example.
• get_tokens returns token names for a group, such as bg, text, border, brand, status or chart, with their CSS variable and Tailwind utility.
• suggest_composition takes a description of a screen or a task and suggests which components to combine, pointing at existing blocks where one fits.
• validate_jsx takes a JSX snippet and reports unknown components, unknown props, invalid prop values and missing accessible names.

The first four give the agent facts. The fifth checks its work.

Check before answering

The most useful habit an agent can learn is to check its answer before showing it to you. With validate_jsx, the loop looks like this: the agent drafts JSX from what get_component returned, sends the draft to the server, reads the report, fixes the problems and only then replies.

<Button type="primary" size="medium" onClick={save}>Save</Button>

Take the Save button from the demo. Without the server, the agent writes type="primary", size="medium" and onClick. With it, the agent looks up Button, writes this, and confirms the snippet has no unknown props:

import { Button } from "@nexera-ui/react";

<Button variant="primary" size="md" onPress={save}>
  Save
</Button>;

For an icon-only action, the check catches the missing name that a visual review would miss:

import { IconButton } from "@nexera-ui/react";
import { LuSettings } from "react-icons/lu";

<IconButton aria-label="Settings" icon={<LuSettings />} variant="ghost" onPress={openSettings} />;

Validation will not replace your type checker or your tests. TypeScript already rejects most of these mistakes once the code is in your project. The point is to catch them inside the agent's loop, so you never receive the broken draft in the first place.

Setting it up

Once @nexera-ui/mcp is published, adding it to Claude Code is one command:

claude mcp add nexera -- npx -y @nexera-ui/mcp@latest

In Cursor, add the server to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "nexera": {
      "command": "npx",
      "args": ["-y", "@nexera-ui/mcp@latest"]
    }
  }
}

The server will run locally through npx. We plan for it to answer about the version of @nexera-ui/react your project has installed, so the agent sees the props you can actually use.

What we want to hear

We will keep the MCP page up to date as the design settles. If you already use an agent with Nexera, the most useful feedback is a list of the mistakes it makes most often. Each one is a candidate for a check in validate_jsx. Until the server ships, the component pages list every prop with its type and default, and the get started guide covers installation and the provider.