# I Built an AI-Driven Component Library with Web Components

An AI coding assistant can produce a convincing interface while getting a component's API wrong. A property might belong to another library. An event handler might use the wrong event name. A screen might look right while its form never submits.

For a component library, that raises a practical question: how do you give an assistant enough context to use the components correctly?

My approach with AWC UI is to ship that context alongside the code: component manuals, machine-readable API metadata, project instructions, and an optional MCP server.

That is what I mean by “AI-driven” here: supporting the workflow of building interfaces with an AI coding assistant. The components themselves run as ordinary Web Components in your application.

AWC UI is an MIT-licensed Material Design 3 library built with Stencil. It includes 56+ components, with integrations for React, Angular, Vue, Svelte, and plain HTML. The catalog covers forms, navigation, dialogs, tables, and charts, with shared theming and density controls.

The part I want to explain in this post is how an assistant can discover and use those components.

Start with the documentation for the installed version.

Core includes a library-level guide, main-llm.md, and individual component manuals inside the npm package. This gives an assistant a reference that travels with the dependency installed in your project.

Those manuals cover more than property names. They include component selection, events, slots, styling hooks, keyboard behavior, and common integration mistakes. They also explain when another component would be a better fit.

For example, this is valid AWC UI button markup:

<md-button variant="filled" size="sm" type="submit">
  Save changes
</md-button>

The button manual explains several details that matter when generating the surrounding code:

• sm is the default size.
• loading makes the button inert as well as showing its loading state.
• soft-disabled keeps an unavailable action in the keyboard tab order.
• type="submit" participates in the surrounding form's submission and validation.

These details affect behavior, even when two implementations look similar in a screenshot. They are useful things for an assistant to read before editing a form.

Connect your assistant to those manuals.

With a supported Node version—22.13+ on the 22.x line, or 24+—run this from your app's directory:

npm install @awc-ui/core
npx --no-install awc-ui ai-setup

The setup command adds documentation references to the project instruction files used by Codex, Claude Code, Cursor, and GitHub Copilot. Those references point into the installed Core package.

You can preview the changes first:

npx --no-install awc-ui ai-setup --dry-run

Then give your assistant a task with a clear outcome. For example:

Add a customer settings form to this app using AWC UI. Keep the existing framework, routing, and theme. Include a required email field and a save action. Read the relevant component manuals before implementing, then check keyboard navigation and form validation.

This setup supplies library context. Framework configuration and implementation still follow the needs of your application. The Building with AI guide covers setup and optional build and review skills.

MCP makes the same documentation searchable through tools.

For assistants that support the Model Context Protocol, AWC UI also provides the optional @awc-ui/mcp server.

It exposes four tools:

Tool	What the assistant can retrieve
search_components	Components matching a name or use case
get_component	A component's manual, structured API, or both
list_guides	Available framework, theming, and other guides
get_guide	The content of a selected guide

For clients using an mcpServers configuration, the entry looks like this:

{
  "mcpServers": {
    "awc-ui": {
      "command": "npx",
      "args": ["-y", "@awc-ui/mcp"]
    }
  }
}

The server bundles its documentation and serves it locally after installation. Its tools provide read-only documentation access; your coding assistant uses its own tools to edit and run your application.

Version matching matters here. MCP responses report a coreVersion, which should be checked against the Core version installed in your app. If they differ, the manuals in your installed Core package provide the reference for that application.

Alongside the prose documentation, Core publishes a custom-elements.json manifest describing elements, properties, events, slots, CSS parts, and CSS custom properties. That structured data is useful to IDEs and documentation tools as well as the MCP integration.

The output still needs to be checked.

This setup gives an assistant concrete information to consult. It does not guarantee that every generated interface is correct, and I am not presenting a benchmark claiming a particular improvement in accuracy.

For a generated form, I would still check empty and invalid values, keyboard operation, submission behavior, and the result on a narrow screen. For a server-rendered application, I would also check the framework integration and hydration behavior. Component documentation is one input to that work.

If you want to try the approach, pick one small feature in an existing project, connect the documentation, and ask your assistant to implement it. That makes it easier to inspect the result and identify any missing guidance.

You can explore the live components, follow the AI setup guide, or browse the source on GitHub.

If you use AI tools for frontend development, where do they most often get component libraries wrong: API names, styling, forms, or accessibility? I would like to use those examples to improve AWC UI's documentation and integrations.