MCP server
Give a coding agent the real components instead of plausible ones.
delacour mcpAn MCP server over stdio, exposing the same functions the commands call. Ask an agent for "a
button" without it and you get plausible JSX — the right shape, and none of the parts that matter
here: the icon that inherits its size from the button's context, the spinner that replaces the
icon so the label does not shift, the expo install route for the native modules underneath.
With it, the agent reads the real component and copies it.
Wiring it up
claude mcp add delacour -- bunx delacour@latest mcp--registry and --ref work here too, so an agent can be pointed at a fork or pinned to a
version.
The tools
Prop
Type
add_components is the one to reach for. It writes native-components.json, wires Metro and the
Tailwind globs and copies the theme in before it copies the component, so it works against a bare
create-expo-app. init_project exists for the case a default cannot infer: components belonging
to a package several apps share, or a source directory this project spells differently.
Two things no tool can do for you
Importing the CSS entry as the first statement of the root layout, and wrapping the app in
<DelacourProvider>. Both are edits to a file the user owns, and both fail silently — unstyled
components, and presses that never land. init_project names them in its reply and check_project
catches them afterwards.
add_components installs nothing unless asked. Its reply names what it copied and, when something
is missing, the commands that would install it:
Added button, icon, pressable, spinner, text, … — 43 files.
Not installed. These have to be run from the app before it will build:
bunx expo install react-native-gesture-handler react-native-reanimated react-native-svg uniwind
bun add cn tailwind-merge tailwind-variants tailwindcss
Re-run this tool with install: true to have them run for you.
A native module changed — rebuild the dev client; a JS reload will not pick it up.Running someone's package manager unprompted is not the sort of thing to do on an agent's behalf by
default, and the agent cannot see the CLI's own output — the server's stdout is a JSON-RPC stream,
so add runs silent and this reply is the only place the information exists.
check_project is the one worth pointing an agent at explicitly. When a component renders
unstyled or a press does nothing, there is no error message to read — the agent will otherwise
start rewriting working code. Those failures are
configuration, and this names them.
Copying beats generating
get_component returns the component's AGENTS.md alongside its source, rewritten to cite your
own import paths. That document is where the reasoning lives — why isLoading swaps the icon
rather than joining it, why a View cannot cascade colour to a Text, why the separator stretches
instead of taking a percentage width.
An agent that has read it edits the component correctly. An agent that has not writes something that renders and is subtly wrong.
The same prose ships with the files
add writes each component's AGENTS.md next to its source, so the notes are in your repository
whether or not the MCP server is running. That is a real advantage of owning the code: the design
rules travel with it.
Without MCP
Every tool has a command behind it, so an agent with shell access needs nothing installed:
delacour list --json
delacour view button --json
delacour add button --yes # sets the project up first, if it has to
delacour doctor --jsonSee also llms.txt for handing an agent the whole library as
context, and Agents for the conventions it should follow
when editing these components.