Agent support
Give Your Coding Agent a Design System It Can Follow
Start from the components and rules in your installed edition. Give your agent a page requirement, then check the result against the same patterns your developers use.
Watch a Customer Page Take Shape
A real run, with the corrections it needed. Claude Code, VuiAdmin Pro React, the MCP server registered from the download.
Add a customer form with First Name, Last Name and Date of Birth,
with Cancel and Create Customer actions.- 1It asked what a form is here. The server answered with page type 2 and the RecordForm variants, so it wrote a field list rather than three inputs and a button.
- 2It read the props. It asked what RecordView takes and got the props of the installed version, including that formMode defaults to a slide-over.
- 3It produced the screen. A field list, a route, and a row in nav.ts. It compiled and it looked like the product.
- 4It got two things wrong. The generic was left off RecordView, so TypeScript checked the fields against a row with only an id. And the name field drew twice, because getPrimary already renders it and the field needed hideInTable. Both are documented failure modes, both were one line, and neither was caught by the agent.
That is the honest result. An agent with this much context gets much further than one without it, and it still produced two defects a developer had to fix. Any vendor telling you otherwise is selling you something they have not run.
What the Agent Can Discover
- The rules
- AGENTS.md at the root of your download: the conventions this codebase follows, in the form an agent reads first.
- The components
- Every family, its exports and its props, from the source in your download rather than from a model's memory of some other library.
- The page patterns
- Five page types, and which one a requirement calls for. This is the difference between a screen that matches the product and one that merely compiles.
- The tokens
- The theme contract, so generated markup uses your colours rather than Tailwind's palette.
- Working examples
- 116 screens it can read, in the same project, built the way you want the next one built.
How the Workflow Works
- Step 1
Locate the rules
The agent reads AGENTS.md and the MCP server's guide tools.
- Step 2
Identify the pattern
A create form is page type 2, not a hand-built form. The server answers which.
- Step 3
Inspect the API
It asks what RecordView takes rather than guessing, and gets the props of your version.
- Step 4
Compose
Fields, groups, validation and actions, from the field list rather than from markup.
- Step 5
Handle the states
Loading, empty, error and saving, because the pattern includes them.
- Step 6
Run your checks
tsc, your linter, your tests. The agent's output is a diff, not a promise.
What Stays Your Responsibility
- The data model and the backend behind it.
- Authentication, authorization and every business rule.
- Reviewing what the agent wrote. It produces a diff, and a diff is not a decision.
- Your own tests. The agent can run them; it cannot decide they are enough.
Supported Clients
The server speaks MCP over stdio, so any client that reads a .mcp.json picks it up with no setup. Claude Code and Cursor are the two this has been run against. Others should work and have not been tested, which is a different claim and is written as one.
What Your Package Includes
All of it, in every paid edition. The MCP server, the protocol it answers from, the instruction files and the offline documentation are in the download, and none of it is an add-on, a subscription or a hosted service. It works with no network because it reads your own project.