MCP connections

MCP (Model Context Protocol) is a standard that lets AI assistants connect to external tools.

The UXPin Wire MCP server lets AI assistants like Claude, ChatGPT, and Cursor build React prototypes and apps in Wire, create design systems with AI, and generate screens with your own Merge component library.

This is useful if you already work with AI agents day to day: point your existing setup at UXPin Wire, describe what you want to build, and get a working MVP or design system without switching tools.

What you can build with UXPin Wire MCP

• Projects and MVPs. Describe an app and get a working React app you can preview and share.
• Design systems. Create a design system with AI from your brand colors, typography, and guidelines, built on MUIv9 framework. Fully themeable.
• Apps on your Merge library. Build screens with the real components from your own UXPin Merge library, so what you build matches production.
• Landing pages. Generate static HTML landing pages from a prompt. Fully themeable.

How to connect an assistant

Add UXPin Wire as an MCP server in your assistant, then sign in to your UXPin account when asked. The setup is the same idea everywhere: give the assistant the Wire server address and authorize it.

1. From the Wire Dashboard, open Connect an assistant in the top bar, next to Collections management.
2. Select the AI assistant to open instructions specific to it.
3. Copy the server URL: "Https://api.uxpin.com/mcp" and add it as a custom connector in your AI agent.
4. Connect. You'll be sent back to Wire to sign in and approve access.
5. Start a new chat and ask the assistant to list your Wire projects. If it answers, you're connected.

What the assistant can do

Once connected, your assistant can create, read, and edit Wire projects, and manage your design systems, all from the chat.

Projects

• Create a project from a template: shadcn/ui, MUI, Ant Design, React Bootstrap, or a static HTML landing page.
• Build on your own Merge component library.
• List and search your projects, and get the editor and preview links connected to your Wire builds.
• Inspect Wire project's file tree and read its files.
• Download a project's structure to rebuild it outside Wire.

Code

• Write new files and edit existing ones.
• Delete files. The entry point and package.json are protected.
• Follow the template's coding rules and design guidelines before it writes anything.
• Check component props and presets in custom library projects, so it doesn't guess.

Design systems

• List your saved design systems and the predefined template gallery.
• Create design system guidelines from colors, typography, spacing, radii, shadows, and component styles, plus written rules like an overview and do's and don'ts.
• Build on your own Merge component library.
• Add a component catalogue or art direction to the guidelines.
• Export a project's guidelines as a DESIGN.md file inside the project.
• Update, create or delete an existing design system.
• Apply a design system to a project, or remove it.

Design systems and Merge libraries

These are different things, and you can use them together.

Building a Design System

To create your own Merge library select a Design System option in Wire dashboard. A Design System project works best when you give the assistant your design system guidelines, or describe the details yourself: colors, typography, spacing, and the components you need. MUI v9 is only the starting framework, so the more you specify, the closer the library gets to your brand.

Design System project is a library to shape, not an app to build. Here is what the assistant does in it.

• Change the look. Colors, fonts, roundness, and density are edited as design tokens in a single theme file, for light and dark mode. Components are never restyled one by one.
• Name the system. On the first request it gives the library a short name and renames the tokens after it.
• Add a component. It creates the component with a default preset, adds it to the library manifest, and lists it in the documentation site, so it shows up in the navigation and the gallery.
• Change a component. It edits the component and its preset and keeps its name and path, so the published library keeps the same identity.
• Write the guidelines. A DESIGN.md in the project explains how the tokens are meant to be used. The assistant updates it together with the tokens.

Note that screens, pages, and routes don't belong in a Design System project. To build an app with the library, create a separate project on it. The assistant picks the right template from how you word the request, so it's important to name the thing you want. Try prompts like these:

• To create a design system: Create a new Design System library in UXPin Wire. Make it a fintech system with navy and amber, sharp corners, and high contrast.
• To create it from your design system guidelines: Create a new Design System library in UXPin Wire from "Xyz" design system guidelines.
• To add a component: Add a StatCard component to my Design System "Xyz" project.
• To change the look: Make my design system warmer and rounder.
• To build an app on a library: Create a new UXPin Wire project on my [library name] Merge library and build a login screen.

Good to know

• Projects are frontend-only and compile in the browser. Node built-ins and server-side packages don't work.
• Navigation uses hash-based routing, so each screen has its own address in the preview.
• Each component lives in its own file, under about 400 lines.

Best Practices

Good results come from a clear brief and small steps. These habits make the biggest difference.

Brief it like a teammate

A short brief beats a long list of screens. Cover who it's for, what they need to do, and how it should feel.

'Build an internal approvals tool for our procurement team. Managers review purchase requests, filter them by status and amount, and approve or reject with a comment. Use our Merge library and design system guidelines. Use 20 mock requests with realistic vendors and amounts.'

Set the look first

Choose a template and a design system before you ask for screens. Every screen then follows the same colors, type, and spacing, and you don't restyle later.

Build in passes

Ask for one thing at a time, and check the preview after each pass.

1. Structure: pages, navigation, and the main flow.
2. Content: real copy, realistic data, and empty states.
3. Polish: spacing, states, and small details.

Say exactly what to change

The more specific the request, the fewer rounds you need.

Keep the assistant on track

In a long chat, the assistant can drift from your original look or forget earlier decisions. Ask it to re-read the project files and the design system guidelines before it continues. If it still drifts, start a new chat with a short summary of what you've built.

Use real content

Tell the assistant the names, numbers, and wording you expect to see. You can upload any notes, PDFs, and sheets too. Prototypes with realistic content are easier to judge and to test with users. Since projects have no backend, ask for mock data where a server would normally respond.

Double-check before taking major action

Before the assistant deletes files or changes a saved design system, check what it plans to do. Both can affect more than the screen you're looking at.

Troubleshooting