Components and agents: reuse instead of inventing

An AI agent duplicates components when it does not know what exists. How to document your system so it reuses it, with Storybook MCP, Figma MCP and shadcn/ui.

info Quick Definition
Reusing components with an agent means the AI looks through your component system for an existing element before creating a new one, and uses it with its documented props and variants. For that to happen, the component catalog has to be readable by a machine.

Why does an agent invent components you already have?

An agent does not remember your library. If you ask it to “add a confirmation modal” and do not show it the one that already exists in src/components, it will write a new one with its own styles, its own close logic and probably without the focus handling your team already solved.

The result looks correct in a quick review, but it accumulates debt: two different modals, two buttons with different radii and three ways to show an error. This is what happens when a queryable design system is missing, only at the speed of an agent.

What does it mean for a component to be “readable by AI”?

A component is readable when an agent can answer four questions without guessing:

  1. What is it called and where does it live?
  2. Which props does it accept and which are required?
  3. Which variants and states does it have?
  4. When should it be used, and when should it not?

The fourth question is the one most often forgotten. A component without usage rules gets used badly even when the agent knows its API. It is the same principle of a good design system for people: document the intent, not only the shape. To go deeper, see a design system AI can read.

How do the tools solve it?

Three official tools show the same pattern: the agent queries a catalog before it writes.

  • Storybook MCP. It is an addon (npx storybook add @storybook/addon-mcp) that exposes an MCP server with three groups of tools. The docs group (docs-list, docs-show, docs-show-story) returns the component index, props and stories. The development group helps write and preview stories (for example, stories-preview), and the testing group has test-run. The documentation depends on a components manifest that is off by default and is turned on with features: { componentsManifest: true }. It only works with React, Angular with Vite and Vue 3 with Vite (the latter also needs experimentalDocgenServer). In other frameworks, the development and testing tools are still available, but the docs tools are not. Everything is in preview and the API may change.
  • Figma MCP. search_design_system searches components, variables and styles in the connected libraries, and several searches can be sent in one call. get_code_connect_map returns, for each instance in your selection, the code component it is mapped to. That mapping exists only if someone has set up Code Connect, the bridge between Figma components and code components, available with a Dev or Full seat on the Professional, Organization and Enterprise plans. For the full flow, read Figma to code with MCP.
  • shadcn/ui MCP. If your system is distributed as a registry (the shadcn/ui model), the shadcn MCP server lists and searches components, blocks and templates from the registries configured in components.json, and installs them from requests such as “add a login form”. It accepts third-party and private registries, such as a company’s internal library, using authentication headers. It is started with shadcn@latest mcp init.

The practical difference: Storybook answers “how is this component used”, Figma answers “which code component matches this design”, and the shadcn registry answers “what is available to install”.

How do you document a component for an agent?

Write the documentation as if it were for a junior who starts on Monday. Include:

  • A usage paragraph: “Use it to confirm a destructive action. Do not use it for navigation.”
  • The props table, with types and default values.
  • A minimal example that compiles.
  • The cases where it should not be used: “Do not place it inside another modal.”

This documentation also enters the agent’s context, so it has a cost: every line you write takes up space. Prioritize usage rules over obvious descriptions. And leave a short rule in the repository’s standing instructions, such as a CLAUDE.md or AGENTS.md file (more here): “Before creating a component, search the catalog; if you do not use an existing one, explain why”.

When should you NOT force reuse?

  • When the existing component does not fit the case and adapting it would break it. A component with twenty conditional props is harder to maintain than a new, simple one.
  • When the system is being rewritten. Asking the agent to reuse components you are about to delete produces work that gets thrown away.
  • When there is no catalog. Without documentation, the agent can only guess, and reusing a guess is worse than writing new code.

Example

Illustrative example: a team has a ConfirmDialog component with the props title, onConfirm and variant="destructive". They document it in Storybook with a usage sentence and an example. Then they ask an agent with Storybook MCP: “Add confirmation before deleting a project.” The agent calls docs-list, finds ConfirmDialog, reads its props and uses it with variant="destructive". Without the documentation, it would have written its own modal.

What to review: that the agent did not create a new component in src/components with a similar name. A search by name in the repository catches it in seconds.

Common mistakes

  • Documenting only the props and not the usage. The agent knows how to call the component but not when.
  • Leaving duplicate components in the repository without marking which one is official. The agent will pick the first one it sees.
  • Assuming Storybook MCP works the same in every framework. Check support before counting on it.
  • Forgetting to turn on the components manifest: without it, the docs tools are not available.
  • Letting the agent create a new component without asking for a justification. Ask it to explain why it did not reuse an existing one.
  • Not checking the accessibility of the result. Reusing a component does not guarantee that the new case is accessible.

Sources

Frequently asked questions

Why does an AI agent create duplicate components?
Because it does not know they already exist or has no way to query them. Without a readable catalog, the agent tends to generate a new button or modal every time it needs one.
What can Storybook MCP do to prevent it?
Its documentation toolset lets the agent list components, read their props and examples, and reuse them. It is in preview. According to Storybook, that part only works with React, Angular with Vite and Vue 3 with Vite, and requires turning on the components manifest.
How does Figma MCP help reuse components?
With the search_design_system tool the agent searches components, variables and styles in the connected libraries. With get_code_connect_map it sees which code component corresponds to each Figma instance, if the team has set up Code Connect.
What documentation does an agent need to use a component well?
The props it accepts, its variants, when to use it and when not to, and a minimal example. That is the information the agent reads before writing code.