Connect your design system guidelines to AI tools

Connect your brand once so your AI tools build with your guidelines and design tokens. UI Rules uses MCP (Model Context Protocol) to bring your colors, typography, spacing, and design decisions into the build.

Choose your tool below for its setup instructions. The rest of this page explains what the connection shares and how access works.

Per-tool guides#

What gets served#

When a tool connects, UI Rules exposes three things for the brand:

• Styles. Your token values for color, typography, radius, shadow, spacing, and sizing, with light and dark values where they apply.
• Rules. Your authored guidelines, each with its text, Guidance (Do, Don't, Caution, or Info), and Importance (Required, Recommended, or Optional), grouped by where they apply.
• Component vocabulary. The components and blocks that are switched on, including any variants that are switched on.

Your connected AI tools read the relevant guidelines, apply your design tokens, and check their work against your design system. Your brand shapes the build from the start.

What a tool can change depends on the permissions its connection carries. See What a tool can change.

Signing in or using a key#

Every guide connects by signing in. The tool opens a UI Rules page in your browser, where you sign in if asked, select the project, and click Authorize. There is no key to copy.

Signing in uses your own key for that project, or makes one for you if you have none, so the connection is yours to revoke and it ends when you leave the organization. A key made this way can do everything except import tokens into the brand.

If you would rather paste a key, open Connect in the workspace top bar, pick your tool, and open Use an API key instead. Claude, Codex, Cursor, Lovable, and the custom connection offer it; Figma Make, VS Code, and v0 connect by signing in only. Create API key makes one in one click with full access to the project; Choose permissions lets you limit it first. The key is shown once, and the steps below it already include it. Every key the brand has is listed on its API keys page.

A key identifies the project and the organization on its own, so there is no project id, tenant id, or account name to configure anywhere. Keys look like this:

uir_sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Connecting#

Every tool connects to one endpoint:

https://mcp.uirules.com/mcp

It is a remote server over streamable HTTP. There is no local process to install and no stdio bridge.

A tool that uses a key sends it as a header, in either of two forms. Most tools take the first:

x-api-key: uir_sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Authorization: Bearer uir_sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

The command line (soon)#

A CLI that writes the config file for Claude Code or Cursor, and exports your tokens as a file, is coming. It is not published yet, so the per-tool guides above are the route today. See Command line for what it will do.

What a tool can change#

Serving the ruleset, the tokens, the export, and validation needs only read access. A key limited to Delivery only carries nothing else.

Six tools do change your design system, and each needs its own scope. A key made in one click, or by signing in, carries the scopes for rules, rule groups, and token values; only a one-click key can also import tokens into the brand. Choose a key's permissions when you create it to leave any of them out. Without the scope a tool gets a clean refusal and everything else keeps working.

• Add a rule attaches a new rule to one project. Your brand's own ruleset is untouched and no other project sees it.
• Update a rule changes an existing one. A rule the project owns changes in place; an inherited one is customized for that project only, and your brand keeps its own.
• Add a rule group adds a heading that organizes rules within one area, such as Button > Accessibility. It is added to the project only, like a rule.
• Set a token value changes one token for one project, as that project's override. Your brand keeps its own value and other projects are unaffected.
• Import tokens takes a block of CSS you paste. By default it writes overrides for one project; pointing it at the brand is a separate grant.
• Import tokens from a site reads a site's tokens. By default it writes them as overrides for one project; pointing it at the brand, which every project inherits from, is again the bigger grant.

Updating a rule, setting a token value, and both imports always show a preview first, and write only after you approve that exact change.

A separate set of session tools lets an agent keep its own notes and send feedback. Those write to UI Rules' own storage, never to your brand's rules, and they also need their own scopes.

For every tool by name, the order the server asks agents to use them in, and the scope each needs, see the MCP tools reference.

Brand scope vs project scope#

The key you use determines what a tool sees.

• Brand is the source of truth. It is served untouched and inherited by every project.
• Project serves the same brand ruleset plus its own sparse overrides. On conflict the project wins, and the brand is never modified.

Because each connection belongs to one project, connect a tool to the project whose effective view you want it to follow. The project overview lists its overrides, so you can confirm what it resolves to before you connect.