MCP for UI components: boundaries before the demo

Write the boundaries before you wire the connector, or you will spend onboarding week untangling rules files that fight the agent. MCP for UI components is connecting a coding agent to your design-system context through a Model Context Protocol server, with written limits on what the agent may read and change. The demo is easy. The part that saves your sprint is deciding, on paper, what the connector is allowed to touch and who owns it when it touches the wrong thing.

The trap is not that the connector fails. It is that the connector succeeds at things nobody listed. A green CI run tells you the commands ran. It does not tell you which servers fired, which folders got rewritten, or whether a reviewer could explain the change without replaying a chat log. That gap is where the rework hides.

Pin down what the connector may touch

Most MCP connectors ship as capability demos: here is everything this server can do. That is the wrong default for a shared design system. Least privilege needs an explicit trust boundary, and the MCP specification gives you the vocabulary for scoping it.

The fix is one markdown card per server. List the allowed actions, the forbidden actions, the owner, and the rollback path. Once that card exists, operators know what "off" looks like, and review has something concrete to check against.

# Connector card: design-system MCP server

owner: @frontend-platform
rollback: revert PR + `pnpm dlx reset-tokens`

allowed:
  - read component metadata and token values
  - propose diffs to `packages/ui/**`

forbidden:
  - write outside `packages/ui/**`
  - call any undeclared MCP domain
  - touch CI config or release scripts

Make precedence explicit in CLAUDE.md

Permission creep with Claude Code, Anthropic's coding agent, looks harmless: bash approvals become muscle memory, and sessions start inventing policy mid-run. You stop that by writing precedence down before any session starts.

Put it at the top of CLAUDE.md: which hooks win, which folders need human eyes, and where temporary overrides live. The getting started docs cover the mechanics. The point is that the agent never has to guess the rule, because the rule is already on the page.

Leave a replay trail in AGENTS.md

A merged green PR that no reviewer could trace back to intent is verification theater. It looks reviewed. Nobody actually saw the transcript. With CLI agents like Codex, OpenAI's coding agent, this is the most common way rework sneaks through.

So require three things in the PR, in order: an intent line, the command transcript, then a diff summary. The Codex quickstart workflow slots this in cleanly. Now review is reproducible without anyone standing behind a terminal.

Make every child agent return a receipt

When you chain agents, summaries quietly replace receipts, and the deeper the stack the blurrier the handoff. It is the telephone game with merge rights. The parent green-lights a diff it cannot actually account for, and ownership of a shared component drifts away from the team.

The rule is small: every child agent returns the paths it touched, the commands it ran, and the tests proving the regression guards held. No receipt, no merge. Here is a delegation snapshot you can drop in and adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

What the reviewer actually checks

A reviewer should not need the chat history to sign off. Give them a short table of gates and a checklist, and the audit trail stays the shortest reproducible thing in the PR.

• Scopes in the PR body match folders in the diff.
• Primary-doc links were smoke-checked after publishing edits.
• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.

Agents amplify whatever clarity already lives in your files, hooks, and scopes. Wire a connector to a vague contract and you have amplified the vagueness. The same discipline at higher concurrency is the whole game in running multi-agent teams, and the broader practice sits under AI coding governance.

Common questions

• What does MCP for UI components actually change in the workflow?

  The agent stops guessing at design-system context and reads it through a connector instead. That is the gain and the risk in one move: the connector can reach whatever nobody scoped. A card naming allowed actions, forbidden actions, owner, and rollback keeps that reach explicit and reviewable.

• How do you stop an MCP connector from touching unlisted data?

  Write the trust boundary before the demo. One markdown card per server with allowed and forbidden actions, an owner, and a rollback path. Then have review check connector truth on every merge: which MCP servers fired, and whether they were the ones you expected to fire.

• Why do agent PRs need receipts when CI is already green?

  Green CI proves commands ran, not that the team can explain the change. Receipts close that gap: scopes in the PR body, pasted verification output, and child receipts for chained work. Together they turn agent output back into team-owned work that survives review without replaying the session.

• Where should the precedence rules live?

  At the top of CLAUDE.md, before any session starts. Write which hooks win, which folders require human review, and where temporary overrides go. When precedence is on the page, the agent never invents policy mid-run, and a reviewer can see the rule the session was supposed to follow.

Start with the server you already run

Pick the UI-component MCP server you use today and write its connector card now, owner and rollback filled in. The full governance model, cards, gates, and rollout order, is in our white paper if you want the rest before wiring the next one.