How to choose a design MCP

1. What the tools return

Read the tool list before anything else; most clients can show it. A tool that returns a finished design gives the agent decisions that were made together: type against spacing, colour against surface, motion against layout. A tool that returns fragments gives the agent parts and leaves the composition to the model, and composition is where generated pages go generic.

Neither is wrong. Fragments suit a team with its own design system. Finished designs suit anyone who would otherwise start from a blank prompt.

2. Who made the designs

A library made by one team has one standard. An open marketplace has as many standards as contributors, and the agent cannot tell a careful design from a careless one; it will build either with equal confidence. Look for a named maker and a stated rule about what goes in.

3. Sign-in and permissions

Prefer a server that signs in through the browser with OAuth over one that asks you to paste a long-lived key into a config file. Then look at what the tools can do. A tool that reads a library is a small grant. A tool that can write to your files, your design documents or your hosting is a larger one, and you should know which you are connecting. Permissions and safety covers this in more depth.

4. What counts against your plan

An agent can call tools many times in one session, so find out what each call costs before you let it work. The question to ask of any server: does looking count, or only taking? If browsing is metered, a curious agent can spend your allowance on a search.

5. Whether results are checked

A design that looks right in a preview may not rebuild well from the material the server returns. Ask the maker how the returned material was verified. If the answer is that nothing was, plan to do the verifying yourself on every build.

How our own server answers these

• Returns: whole templates. Getting one returns its prompt and, when your plan opens it, its Vite + React project.
• Made by: the ubernatural design team. Nothing in the library is uploaded by third parties.
• Sign-in: OAuth in the browser. There is no API key to copy.
• Counting: browsing the library does not count toward a free account's templates. Getting a template counts the same as taking it on the site.
• Checking: each template is rebuilt from its prompt alone before it goes live.

Apply the same list to every other server

We make uberdesigner, so the list above is a maker describing its own product. Hold it to the five questions, and hold every other server to them as well. Design tools and component libraries publish their own MCP servers; their documentation is the place to find their answers, and we don't summarise them here because they change.

A request that makes the agent show you a server before you rely on it

Before we use the [server name] MCP server for any work, inspect it and report. Do not call any tool that writes, creates, deletes, publishes or spends anything.

1. List every tool the server exposes: its name, what its description says it does, and the inputs it takes.
2. Sort the tools into three groups: read-only, writes to something of mine, and unclear from the description. For the unclear ones, quote the description.
3. Tell me how I am signed in to this server: a browser sign-in or a key in a config file. If a key, tell me which file it is in. Do not print the key.
4. From the descriptions alone, tell me which calls might count against a plan or a quota. Say "not stated" where the description doesn't say.
5. Tell me what kind of material the read tools return: whole designs, parts, or the contents of a file.

Keep the report under 300 words. Then stop and wait.

Written for this page as a starting point; swap the parts in [brackets] for your own. The full prompt of each uberdesigner template is longer and specific to one finished design, and it is tested by rebuilding the template from the prompt alone.

Keep reading

• What is a design MCPA plain definition of a design MCP server, what it replaces in a design-to-code workflow, and the things it does not do.
• What to ask a connected agentFive habits for requests to an agent with a design MCP: browse first, compare options, name the template, say what is yours, and tell it to keep the design.
• Design MCP permissions and safetyGood practice for connecting any MCP server to an AI agent: trust, what tools ask for, browser sign-in over pasted keys, and reviewing what the agent writes.

• Cursor and editors
• Codex and terminal agents
• Whole websites