MCP Server

The ReUI MCP server connects your coding agent to the live ReUI registry. Through one endpoint your agent searches the full library with scored, intent-based matching, reads real component APIs, and gets exact shadcn CLI install commands - so it ships real ReUI instead of guessing.

https://mcp.reui.io

The server runs over Streamable HTTP and works with any MCP-capable agent. It is free with a ReUI account: the first connection opens a "Sign in with ReUI" approval in your browser, and a free account is created in that flow if you do not have one.

The tools

Every tool answers against the current registry, scored and ranked.

Find

• search - ranked matches across components, examples, blocks, and icons for a natural-language query, each with an install command, live preview, docs link, and the components it uses.
• search_icons - the best-matching icon for many concepts ("save", "user settings") in one call, optionally pinned to one icon style.
• list_components - the 20 free ReUI building blocks (data-grid, event-calendar, gantt, kanban, filters, icon-tile, ...).
• list_block_groups - the top-level block groups (application, ecommerce, marketing, ...) with counts.
• list_block_categories, list_example_categories, list_icon_categories - the categories of each type with item counts, for narrowing a search.

Read

• get_component - the inline API (props and usage) for one or many components in a single call, so props come from the docs, never from memory.
• get_examples - a component's real, working example compositions to copy instead of hand-rolling.
• get_block, get_example, get_icon - full metadata for one item by name: description, components used, dependencies, install command, docs and preview links.

Plan and validate

• compose_page - turns a whole-page intent into ordered sections, each matched to the best block for the job.
• validate_usage - checks planned components and props against the documented API before any code is written.
• get_audit_checklist - the ReUI-specific checks to run after installing and adapting an item.

Install and unlock

• get_install_command - the exact shadcn CLI command for an item, validated against the registry (wrong names get did-you-mean suggestions, not a fabricated command).
• get_project_context - the components.json registry config and license-key setup so shadcn add @reui/... works.
• get_agent_skill - the full ReUI build skill, served at runtime to agents that cannot install files.

Connect in three steps

The flow is the same in every agent; only where you paste the endpoint differs.

Authentication

Every request carries a credential - there is no anonymous access - and which kind you use comes down to one question: can this machine open a browser?

With a browser, use OAuth. This is the path almost everyone takes, and nothing gets pasted anywhere. Your agent connects, receives a 401 whose WWW-Authenticate header points at ReUI's discovery documents, registers itself (ReUI supports dynamic client registration, so there is no client id or secret for you to create), and opens the "Sign in with ReUI" approval in your browser over PKCE. Approve once and your agent stores the tokens and refreshes them on its own from then on. A free ReUI account is created in that flow if you do not have one, and every connection can be reviewed or revoked later at Account → MCP.

Without a browser, use a personal token. Covered in full below.

If your agent gets stuck signed out

An OAuth connection can die outright: you revoked it, its 60-day refresh token lapsed, or its stored token was invalidated for safety after a suspicious reuse. From then on every refresh answers invalid_grant, and many agents quietly retry that forever instead of asking you to sign in again, so the only symptom is ReUI tools that stopped working. The stored credential is dead and no amount of retrying revives it. The fix is one step: make the agent sign in again, either from its own reconnect or sign-in action, or by removing and re-adding the ReUI MCP server, which triggers a fresh browser approval. Account → MCP shows the connection as Disconnected when this is the state you are in.

Headless and CI

Some environments can never show you an approval screen: a CI job, a remote shell over SSH, a container, a cron task. For those, skip OAuth and carry a personal token instead.

Create the token

Go to Account → MCP and create a personal token. It looks like reui_pat_..., and it is shown once, at creation. ReUI stores only a hash of it, so a lost token gets replaced rather than recovered. You can hold up to 20 active tokens, which is enough to give each pipeline or machine its own.

Send it as a Bearer header

Every request carries the token in an Authorization header:

Authorization: Bearer reui_pat_...

In an MCP client config that is a headers entry on the ReUI server. In a script it is one -H flag:

curl -sS https://mcp.reui.io \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H "authorization: Bearer $REUI_MCP_TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"0.0.0"}}}'

The accept header is not decoration. MCP's Streamable HTTP transport requires the client to list both application/json and text/event-stream, and this server answers a POST with an SSE stream, so a request that omits it fails. A working token returns 200 with the JSON-RPC result delivered as an SSE event; a bad one returns 401 with a WWW-Authenticate header and a JSON-RPC error that names the actual problem (expired, revoked, or an unexpanded placeholder).

Whether you can write ${REUI_MCP_TOKEN} in that config instead of the token itself depends on your client, so check its guide rather than assuming. Some do expand it - Claude Code substitutes ${VAR} in a server's url and headers, and VS Code has its own ${env:...} and ${input:...} syntax. Many do not, and there a ${...} placeholder is sent as literal text and comes back as a 401. When in doubt, paste the real value into a file you never commit.

Lifetimes, and the silent expiry

A personal token expires. The default is 90 days; 30, 60 and 180 days are offered too, along with No expiry for pipelines that genuinely cannot rotate.

Nothing warns you before one lapses. There is no expiry email and no grace period, so the first sign is usually a green pipeline turning red. When it happens, the token returns 401 and has to be replaced, not re-authenticated: a personal token has no refresh, so signing in again does nothing for it. Create a new one at Account → MCP and update the secret. The same page revokes a token if one ever leaks, and a revocation takes effect at the server within about half a minute.

Store it in a CI secret

Treat the token like a password: it authenticates as you and carries your plan. Put it in your CI provider's secret store and read it from the environment at run time, exactly as the $REUI_MCP_TOKEN above does. Never commit it to a config file that lands in the repository, and prefer one token per pipeline so you can revoke a single leak without taking down the rest.

Set it up in your agent

Pick your agent for its full setup guide: