Give your coding agent a component system

A coding agent builds UI from what it knows. Left alone it reaches for the same few pieces in every app: a text input for an age, a dropdown for three choices, a card around everything, the chart library's default colours. The app works and looks like every other app its agent wrote this month.

Beamline changes what the agent knows. Through one MCP server it gives the agent 190 designed React components and screens, says what each one is for and what to use instead, installs only the ones a screen needs into your repo, and checks the result. This guide walks through exactly what happens, so you know what your agent is doing and why.

The short version

1. Add the MCP server https://mcp.beamline.io/mcp to your agent and sign in (Google, GitHub or an e-mail code).
2. In your app's folder, run the connect command once, so every later session knows Beamline is there.
3. Ask for a screen. The agent reads the menu, maps every field to a part, installs those parts, builds, and runs the audit before it says it is done.

Each agent's exact steps are on its own page: Claude Code, Codex, Cursor, VS Code, Gemini CLI, Windsurf and any MCP client.

Step 1: the agent reads the menu

The server offers three tools, and its instructions tell the agent to use them in order before it writes any UI.

The instructions are short on purpose. Codex decides how to use a server from the first 512 characters of its instructions, and Claude Code cuts instructions and each tool description at 2,048 characters, so Beamline's open with what it is, when to reach for it and the order of the tools.

Step 2: every field gets the most specific part

Before installing anything, the agent maps each field and pattern on the screen to a part and writes the table into the app's BEAMLINE.md (field, part, why). The menu pushes it past the familiar defaults:

• an age is a number field or a slider, not a text input;
• two to five choices are a segmented control or a radio group, not a dropdown;
• choices that need a sentence each are radio cards;
• steps are a stepper, and a headline number is a metric card.

An input, a select or a plain card needs a reason in that table. That one rule is most of the difference between a generated app and a designed one.

Step 3: one install, only what the screen needs

The agent calls beamline_install once with every part it mapped and a look (Prism by default: black, neutral glass, a white main action). It gets back one command to run in the app folder. The install link in it works for 30 minutes, names the exact version your licence covers, and installs:

• only the chosen parts, as compiled packages by default, or as plain React source you can edit;
• one stylesheet, imported once in the app's entry (app/layout.tsx in Next.js);
• the look, applied by wrapping the app once in UIRoot.

import { UIRoot } from "@beamline/runtime";
import { prism } from "@beamline/look-prism";

export function App({ children }: { children: React.ReactNode }) {
  return (
    <UIRoot preset={prism} theme="dark" className="look-page" style={{ minHeight: "100dvh" }}>
      {children}
    </UIRoot>
  );
}

Your package.json lists only what was chosen. React stays yours: the installer never changes your React version and stops with a message if your range does not allow React 19. The install docs cover both paths in full.

Step 4: props from the source, never guessed

Before writing each part, the agent calls beamline_component for it. Every Beamline part follows the same API (variant, size and tone; value, defaultValue and onValueChange for anything stateful; className on the root), so after a few parts the agent rarely surprises you, and the component text gives it the rest: the import, the required props and examples it can copy. The conventions are the same rules, written for people.

Step 5: the audit catches the shortcuts

When the screen is built, the agent runs the audit its install answer named. It reads the app's source and names each fallback with the part that fits: a raw <input>, a text field holding a number, a select with three options, a hex colour where a token belongs. The agent fixes every line marked FIX before it calls the screen done. In Claude Code the connect command also adds a Stop hook (unless you pass --no-hook), so the audit runs whenever the agent tries to finish.

What the connect command writes into your app

Run once per app folder:

npx --yes -p https://mcp.beamline.io/cli.tgz beamline-connect --hosted https://mcp.beamline.io/mcp

It writes, and is safe to run again:

• the MCP server entry beamline in .mcp.json (Claude Code) and .cursor/mcp.json (Cursor);
• a marked Beamline block in AGENTS.md and CLAUDE.md, and a Cursor rule in .cursor/rules/beamline.mdc, so every session in the app starts knowing the workflow without being reminded;
• a short Beamline skill, in .claude/skills for Claude Code and .agents/skills for Codex (Codex does not read .claude/skills).

The block matters more than it looks. Codex loads MCP tools only when it decides it needs them and never shows the server's instructions, so without that block in AGENTS.md a Codex session in your app would not know Beamline exists.

Signing in and who gets what

The first time the agent calls the server, it asks you to sign in. The free sample opens for anyone signed in. The complete system is one payment of $49 with a year of updates, and what your team buys, everyone on the team gets: there are no seats. A part outside what you hold comes back marked, with the name of the pack that has it, so the agent can pick another or tell you.

What to ask for

Name the screen and the data, not the components: "a sign-up page with name, work email, password and team size", "a settings page for profile, notifications and billing", "a trading screen for BTC perpetuals on our feed". The menu includes whole screens for the common ones (sign-up, settings, a CRM pipeline, an analytics home, an agent workspace, a trading terminal), so the agent starts from a designed screen and wires your data into it.