Claude Code Component Library: Reusing Real Components Through MCP

Key answer: A Claude Code component library is a curated set of reviewed UI and 3D components that the agent can browse and install through an MCP server, instead of regenerating each component from model memory. You register the server once in Claude Code, the agent discovers the tools it exposes — list, preview, install — and when you ask for a hero section or a product viewer, it resolves a component id to real source files and writes them into your repo. This turns "generate a component and hope it compiles" into "install a known-good part and adapt it," which is the reliable pattern for anything beyond throwaway snippets. The AETumi MCP exposes exactly this kind of library so Claude Code installs production Three.js and React components rather than improvising them.

Most developers meet Claude Code as a file editor and shell runner, then hit a wall the moment they want a specific, reviewed component rather than a plausible one. A component library reached over MCP is how you cross that wall: the agent stops guessing at a scene and starts fetching a part that already works. This article explains what a Claude Code component library is, how discovery differs from generation, the architecture that makes it reliable, and how to wire it into a real project.

Table of contents

• What a Claude Code component library is
• What you'll learn
• Why component reuse matters
• Architecture: agent, MCP server, library
• Discovery over generation
• The install flow end to end
• Technical implementation and code
• Real product evidence
• Performance and cost
• SEO and shipping the output
• Accessibility
• Production trade-offs
• When to use a component library
• When NOT to use one
• Decision matrix
• Expert notes
• How AETumi approaches it
• GitHub and technical proof
• FAQ
• Related resources
• Conclusion

What a Claude Code component library is

A Claude Code component library is not a folder of files you paste from — it is a catalog the agent can act on. The catalog lives behind an MCP (Model Context Protocol) server, and Claude Code, acting as an MCP client, reads the tools that server advertises. Where a plain library asks a human to find, copy, and wire a component, a library exposed over MCP lets the agent list what exists, select the right entry by id, and install its real source into your project.

The distinction matters because the alternative — asking the model to generate a component from memory — produces something new every time. A component library gives the agent a fixed, reviewed target instead. The files that land in your repo are the same source a human would have chosen, not a fresh guess that happens to look right. If you are new to the protocol itself, Claude Code MCP explained covers the client–server contract this builds on.

What you'll learn

• What separates a Claude Code component library from a copy-paste snippet folder.
• Why installing a reviewed component beats generating one, especially for 3D.
• The agent → MCP server → library architecture in plain terms.
• The full flow from a plain-language request to real files in your repo.
• Concrete MCP configuration and tool-call shapes, with correct Three.js and React baselines.
• When a component library earns its setup cost, and when a one-off snippet is simpler.

Why component reuse matters

An agent generating a component from scratch inherits two weaknesses. First, its knowledge of a library is frozen at training cut-off, so it drifts out of date and invents APIs that were renamed or removed. Second, it has no memory of your standards — your file structure, your prop conventions, your design tokens — so every generation is a coin flip on consistency.

A Claude Code component library removes both. The agent reads the real component at run time, so freshness comes from the library rather than the model's memory, and consistency comes from the fact that every install pulls from the same reviewed source. For interactive and 3D work this is decisive: a WebGL scene either compiles and renders or it fails visibly, and "almost correct" code costs more to debug than it saved to generate. Reuse turns the most breakable part of the job — renderer setup, cleanup, imports — into a solved problem.

Architecture: agent, MCP server, library

Three layers make a component library usable by an agent, and keeping them distinct removes most confusion. The host is Claude Code, which embeds an MCP client. The server is a separate process that publishes a catalog of tools — commonly list_components, get_component, and install_component — plus resources the model can read. Behind the server sits the library itself: the actual source files, each addressable by a stable id. Messages travel as JSON-RPC over a transport — standard input/output for a local server, or HTTP for a remote one.

The consequence is that the agent never needs the library's internals baked in. On connect it reads the advertised schema, reasons about which tool fits the step, and calls it with typed arguments. Add a component to the library and it becomes installable the moment the server advertises it — no retraining, no prompt surgery. The AETumi MCP follows this shape, exposing a 3D and React library through narrow, well-described tools.

Discovery over generation

The core shift a component library enables is from generate to discover. Instead of "write me a scroll-driven hero," the request becomes "list the hero components, then install the scroll-driven one." The agent lists what the server offers, picks by id, and asks the server to place the files. What arrives is coherent source — a component whose imports resolve, whose props are consistent, whose cleanup is already written — and the agent then adapts it to your data and routes.

This is most valuable for compound components. A Three.js hero is not one snippet: it is a renderer, camera, lights, geometry, materials, an animation loop, a resize handler, and disposal, all of which must agree. Generation gets any one of those wrong often enough to matter; discovery hands you a part where they already agree. Browse the kind of parts involved in the 3D components and React Three Fiber collections to see what a reviewed entry looks like.

The install flow end to end

Here is the path a request travels when you ask Claude Code to add a component through the MCP integration:

1. You type a request — "Add the product viewer to the shop page." 2. Claude Code recognizes this needs a capability beyond its built-ins and inspects registered servers. 3. The client selects the relevant tool — list_components to find candidates, then install_component. 4. The transport carries a structured call — tool name plus arguments like a component id and target path — to the server. 5. The server resolves the id against the library and returns the real source files. 6. Claude Code writes them into your project, wires imports, and shows you the diffs to review.

The agent orchestrates and the server supplies ground truth; only the library at the end of the chain changes when you add or update a component.

Technical implementation and code

Registration is the first concrete step. A local server is launched as a subprocess over stdio; the JSON entry looks like this — check current docs for exact key names, which evolve:

{
  "mcpServers": {
    "aetumi": {
      "command": "npx",
      "args": ["-y", "@aetumi/mcp"],
      "env": { "AETUMI_TOKEN": "${AETUMI_TOKEN}" }
    }
  }
}

This tells the client to spawn the server and talk over standard input/output, passing credentials through the environment rather than hard-coding them. Trade-off: a local stdio server needs the runtime installed and starts a process per session, while a remote HTTP server centralizes library updates at the cost of latency and an auth surface to manage.

Once connected, each library operation appears to the model as a typed tool. A list tool advertises itself so the agent can enumerate the catalog:

{
  "name": "list_components",
  "description": "List available components, optionally filtered by category",
  "inputSchema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["hero", "3d", "product-viewer", "ui"] }
    }
  }
}

The typed schema is what lets the agent query the library correctly instead of improvising. Trade-off: an over-broad category or vague description leads to the wrong entry being surfaced, so library authors keep each tool narrow and each component clearly labeled.

When the agent installs a React component, it should preserve the contract that made the component reusable — typed props and a clean mount. A minimal reviewed React wrapper around a Three.js canvas looks like this:

import { useEffect, useRef } from 'react';
import { createHeroScene } from './hero-scene';

export function Hero({ color = '#6699ff' }: { color?: string }) {
  const mountRef = useRef<HTMLDivElement>(null);
  useEffect(() => {
    const el = mountRef.current;
    if (!el) return;
    const scene = createHeroScene(el, { color });
    return () => scene.dispose(); // cleanup on unmount
  }, [color]);
  return <div ref={mountRef} aria-hidden="true" style={{ height: '100vh' }} />;
}

Expected behavior: the component mounts a scene into its container, accepts a typed color prop, and tears the scene down on unmount. The value of a library is that the dispose() call and the ref pattern arrive already correct — the two things an improvised component most often omits. Trade-off: a wrapper this thin still needs a real scene module behind it, which is exactly what the install brings along.

That scene module is where reuse pays off most, because the correct Three.js baseline (r160 ES modules) is easy to get subtly wrong:

import * as THREE from 'three';

export function createHeroScene(container, { color }) {
  const renderer = new THREE.WebGLRenderer({ antialias: true });
  renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
  renderer.setSize(container.clientWidth, container.clientHeight);
  container.appendChild(renderer.domElement);

  const scene = new THREE.Scene();
  const camera = new THREE.PerspectiveCamera(50, container.clientWidth / container.clientHeight, 0.1, 100);
  camera.position.z = 4;

  const mesh = new THREE.Mesh(
    new THREE.IcosahedronGeometry(1, 0),
    new THREE.MeshStandardMaterial({ color, flatShading: true })
  );
  scene.add(mesh, new THREE.DirectionalLight(0xffffff, 2), new THREE.AmbientLight(0xffffff, 0.4));

  renderer.setAnimationLoop(() => { mesh.rotation.y += 0.01; renderer.render(scene, camera); });
  return { dispose() { renderer.setAnimationLoop(null); renderer.dispose(); } };
}

Expected behavior: a single mesh spins under directional and ambient light at a capped pixel ratio. The pixel-ratio clamp and the setAnimationLoop(null) in dispose are the reviewed details a library preserves. Trade-off: setAnimationLoop keeps running even when the canvas scrolls off-screen, so a shipped component should also pause when hidden — a reviewed entry usually does, an improvised one usually does not.

Finally, disposal is the habit that keeps a single-page app from leaking GPU memory as it mounts and unmounts scenes:

export function disposeScene(scene, renderer) {
  scene.traverse((obj) => {
    obj.geometry?.dispose();
    const mats = Array.isArray(obj.material) ? obj.material : [obj.material];
    mats.forEach((m) => m?.dispose());
  });
  renderer.dispose();
}

Expected behavior: geometries, materials, and GPU resources are released when the component unmounts. Trade-off: skip this and a SPA that swaps scenes repeatedly climbs in memory slowly and untraceably — the single strongest argument for reusing a reviewed component over regenerating one that may omit it.

Real product evidence

The clearest proof that a component library beats generation is watching an installed component run untouched. In the walkthrough video accompanying this article, a scroll-driven hero and a product viewer are installed from the library and rendered directly in a Next.js page — no hand-patching of imports, no chasing a missing resize handler. What it proves is the claim this whole piece rests on: the source that lands in the repo is coherent because it was reviewed before it was ever offered to the agent, so the developer's time goes to adapting data and routes, not repairing a fresh guess. These are the same production parts you can browse in the Three.js hub and the 3D components collection.

Performance and cost

A component library reached over MCP adds one round trip per tool call: the agent calls list or install, waits for the server, and continues. A local stdio server keeps that latency tiny; a remote server trades a little speed for centralized updates. The cost is paid per tool call, not per token, so it is negligible against the minutes saved not hand-wiring a scene. The heavier performance story is downstream — the installed component's own runtime cost — which is exactly why a reviewed entry ships with the pixel-ratio clamp and offscreen pause already in place.

SEO and shipping the output

A component library does not change how the page indexes, but the components it installs can. Reviewed 3D and hero components are built to render inside a server-rendered page with real HTML around them, so the scene enhances a page that already has crawlable text and headings rather than replacing it with an empty canvas. That is the difference between a beautiful page that ranks and one that is invisible to a crawler. When you adapt an installed component, keep the meaningful copy in the DOM, not painted into the canvas.

Accessibility

The accessibility win of a library is that good defaults are baked in. A reviewed canvas component carries aria-hidden="true" on purely decorative visuals, respects prefers-reduced-motion by pausing or simplifying animation, and never traps keyboard focus inside a non-interactive scene. When the agent generates from memory, these are the first details to disappear; when it installs from a library, they arrive by default. Still review them — the component cannot know whether a given scene is decorative or the primary content.

Production trade-offs

A component library is not free. You add a server to configure, keep updated, and reason about when something breaks — is it the model, the client, the transport, or the library? For a single component you will never touch again, that overhead outweighs the payoff and built-in file editing is simpler. Be honest about failure modes too: a vaguely described tool surfaces the wrong entry, a flaky remote server stalls a task, and an over-broad token turns a convenience into a risk. The value appears when component reuse repeats — then registering once and asking in plain language removes the most error-prone part of the loop.

When to use a component library

When NOT to use one

Decision matrix

Expert notes

Expert Note — Register once, then it disappears. The mistake teams make is treating the server as per-task friction. It is not: you register the component library once in your Claude Code config, and every future "add a hero" or "install the product viewer" becomes a single sentence. Amortized across a project the setup rounds to zero, and the payoff is that the breakable parts of interactive work — renderer, loop, disposal, imports — arrive already correct.

Expert Note — Keep a human on the install diff. Listing and previewing components is safe to automate; writing files is a side effect. Let the agent freely browse the library, but review the diff before it commits the source into your repo. This is the same discipline you apply to a teammate's pull request, and it is what keeps an agentic loop fast without letting it surprise you.

Expert Note — Adapt, don't re-generate. Once a reviewed component is in your repo, resist asking the agent to rewrite it wholesale for a small change. Ask it to adapt — swap the geometry, rename a prop, wire your data — so you keep the reviewed cleanup and performance defaults. Wholesale regeneration throws away the exact value the library gave you.

How AETumi approaches it

AETumi (aetumi.app) is an AI-native 3D web platform — Three.js and WebGL scenes, React Three Fiber components, and Next.js templates — and it treats its MCP server as the front door to that library for agents. Rather than shipping documentation and hoping an agent copies it correctly, the AETumi MCP exposes narrow, well-described tools so Claude Code can match a plain request to the right component and place real, reviewed source into your repo. The entries behind those tools are the same production pieces you can browse in the 3D components and React Three Fiber collections, so what the agent installs is what a human would have picked. Access ships with the Full Stack plan ($129, buy once, own for life), which also includes full source ownership; the lower tiers (Standard $19, Pro $39, Premium $99) give components and source at their scope.

GitHub and technical proof

The server is open source. You can read exactly how it exposes and resolves library entries in the aetumi-mcp repository — the tool definitions, the input schemas, and how a component id resolves to real files. Reading the source is also the honest way to see its limits: it resolves against one curated library, so it is not a general-purpose package manager, and like any server it depends on a correctly configured client and, for remote use, a network path. The tool calls are lightweight metadata and file operations, not heavy computation, so the cost you feel is dominated by the transport. Treat the repo as the source of truth over any summary — including this one — and see best MCP servers for web developers for how it compares in a wider workflow.

FAQ

How is a component library different from Claude Code just generating a component? Generation asks the model to write a component from memory, where small inconsistencies — a renamed helper, a missing resize handler, an undisposed material — break rendering or leak memory. A component library asks the server for a reviewed entry and installs it as real source, so you reuse working code and adapt it. You trade a guess for a known-good part, which wins for anything beyond a throwaway snippet.

Do I have to build my own MCP server to get a component library? No. You can register an existing server such as the AETumi MCP and use its library immediately. Building your own makes sense only when you have a proprietary internal library you want your agents to install from; for most teams, pointing Claude Code at a maintained server is the faster path.

Does the installed component lock me into a runtime? No — the value is that real source lands in your repo. Once installed, the component is yours to edit, refactor, or remove; it does not phone home. The MCP server is only involved at install time, not at runtime.

Can other agents use the same component library? Yes. Because MCP is an open standard, a compliant server serves any compliant client — Claude Code, Cursor, or Codex. Build or adopt one library and every agent your team uses can install from it, so your investment is not tied to a single tool.

Which plan includes component-library access? MCP-driven installs ship with the Full Stack plan ($129, buy once, own for life), which also includes full source ownership. Standard ($19), Pro ($39), and Premium ($99) give you components and source at their scope; Full Stack adds the agent integration.

Related resources

• MCP overview — how the integration is set up and what it exposes.
• Claude Code MCP explained — the client–server contract this builds on.
• 3D components and React Three Fiber — the installable library.
• Three.js hub — the production scenes behind the components.
• Best MCP servers for web developers — where a component server fits.
• Pricing — plans, including Full Stack with MCP access.

Conclusion

A Claude Code component library turns the agent from a generator into an installer: it browses a reviewed catalog over MCP and writes real, coherent source into your repo instead of improvising a component that may or may not compile. For interactive and 3D work — where a scene either runs or fails visibly — that reliability is the whole point. Register the server once, keep a human on the install diff, and adapt rather than regenerate. Start with the MCP overview, compare plans at aetumi.app/pricing, and read the server yourself in the aetumi-mcp repository.