Teaching Your AI to Use Your Component Library

AI coding assistants keep hallucinating EUI props. You paste in documentation, it gets ignored thirty messages later. You end up debugging code where half the props don't exist.

The fix is an MCP server — about 200 lines of TypeScript that gives any MCP-compatible AI direct access to the EUI source.

What EUI is

EUI (Elastic UI) is Elastic's open-source React component library. It powers Kibana and the rest of the Elastic product suite. The library is large — over 100 components covering everything from basic buttons and forms to complex data grids, drag-and-drop interfaces, and charting primitives. Each component ships with TypeScript types, MDX documentation, and Storybook stories.

It's a serious design system, which also means it's too big for any model to know completely from training data.

Why AI gets EUI wrong

Models know enough from training to be convincing but not enough to be correct. They'll use EuiButton with a size prop that doesn't exist, or reach for a component that was renamed two major versions ago. They can't check themselves, so they commit to something plausible and move on.

Pasting docs into the prompt works until it doesn't. Long conversations push the context out. The model starts guessing again halfway through a refactor.

The MCP approach

MCP (Model Context Protocol) is an open standard that lets AI systems call tools mid-conversation. Instead of knowing things from training, they look them up. This server registers four tools: list all available EUI components, get the source for a specific component, get its MDX documentation, get its Storybook story.

When you ask the AI to build a searchable dropdown, it lists available components, identifies EuiComboBox as the right fit, then pulls the actual TypeScript implementation and documentation before writing a single line. The result looks like this:

<EuiComboBox
  placeholder="Select options"
  options={options}
  selectedOptions={selectedOptions}
  onChange={onChange}
  isClearable
/>

Not because the model remembered the API — because it read the source.

How the server parses the repository

Setup does a shallow clone of elastic/eui (--depth 1 so it doesn't pull the full history). From there, the server builds its index in three passes.

First, it scans every .stories.tsx file under the components directory and reads the component: field from each one. That line always looks like component: EuiButton, — a reliable hook into which components actually exist.

Second, for each component name it converts to snake_case (EuiComboBox → eui_combo_box) and finds the matching .tsx source file. That's the full TypeScript implementation with props, types, and logic.

Third, it reads all the .mdx documentation files and checks their frontmatter for a keywords field. Any doc that lists a component name gets linked to that component. A single component can have multiple documentation pages.

Everything gets written to .cache.json on first run. Subsequent startups load the cache and are instant. If you update EUI, delete the file and it regenerates.

Setup

cd mcp && yarn && npm run setup

The server communicates over stdio, which most MCP clients support. Connecting it depends on your client — for Claude Code it's one command, Cursor and others have their own config format.

What changes

The AI stops confidently inventing props. When it's unsure whether a component accepts a certain prop, it looks it up instead of guessing. The hallucination problem becomes a cache-invalidation problem, which is a much easier thing to deal with.