For Cursor

Cursor reads your repository. It cannot read your design reasoning, because nothing in the repository holds it. Aestheria, the design context layer, is the part it has been guessing at.

The design context Cursor is missing.

Cursor indexes your codebase, holds a plan across files, and applies a diff faster than you can review it. On structure it is genuinely good. The gap is narrower and more specific than "it does not know my brand": Cursor can see that a Card component exists and cannot see when a card is the wrong container, which of your four greys is the border grey, or that this table needs row actions because every other table in the product has them.

Those are the calls that make ten screens read as one product, and they live nowhere Cursor can read. They live in review comments, in a designer's head, and in the tenth message of a thread from March. So Cursor fills the gap with the statistical average of every React app on GitHub, which is a reasonable guess and not your product.

Where the drift actually shows up.

Not in the first screen. The first screen is usually fine, which is what makes this expensive to catch. It shows up in the accumulation:

• Near-miss tokens. A hardcoded #e5e5e5 in one file, --color-border-primary in the next. Both render grey. Only one follows the theme into dark mode.
• Reinvented components. A bespoke dropdown in the fourth feature because the prompt did not mention the one that exists, with its own focus behavior and none of its keyboard handling.
• States nobody asked for and nobody wrote. Empty, loading, error, and permission states are absent until a reviewer notices, because the prompt said "build the invoices table" and Cursor built exactly that.
• Layout that shifts per screen. A 24px gutter here, 32px there, a page title that is h1 on one route and a styled div on the next.

Each one is a two-minute fix and a thirty-second decision, which is why they never get prioritised. Multiply by every generated surface and it is the reason your product looks assembled rather than designed.

Point Cursor at the layer, once.

Aestheria reaches Cursor two ways, and they carry the same content. Over MCP, Cursor queries the live library while it generates: the token list with the rule for each one, a component with its variants and states, a template to build a page against, and validate_snippet, which checks generated markup against the system before you read the diff.

{
  "mcpServers": {
    "aestheria": { "url": "https://mcp.aestheria.design/mcp" }
  }
}

As repo files instead, the kit drops into the project root: AGENTS.md at the top level, which Cursor reads as native context, plus tokens.css and components.css the code imports. No server, no network, and the version is whatever you committed.

Teams working across several products usually run the MCP, so an update reaches every repository at once. A team with one product and strong opinions usually takes the files, edits them, and owns the result. Both are the same system.

What changes in the output.

The generated code references your semantic tokens instead of hex values, so a theme switch is a data attribute rather than a refactor. It imports the component you already ship instead of writing a fourth variant of it. It composes a page the way your other pages are composed, because there is a template describing exactly that. And the states nobody remembers to ask for arrive with it, because the rules that govern them are part of what Cursor reads.

None of this makes Cursor a better model. It narrows what the model has to invent, which is the only part of the problem a design system can honestly address.

• 407 tokens
• 6 themes
• 41 components
• 27 charts
• 63 templates

Questions

How do I connect Aestheria to Cursor?

Add the MCP server in `.cursor/mcp.json` with the URL `https://mcp.aestheria.design/mcp`, or drop the kit in your project root so Cursor reads `AGENTS.md`, `tokens.css`, and `components.css` as repository context. The MCP is free with an account.

Do I need an existing design system first?

No, and this is where Aestheria differs from most tools in the category. Aestheria ships a complete system as starter context: tokens with usage rules, components with their states, patterns, page templates, and six skills carrying the judgment. Most alternatives begin by asking you to bring a system you may not have.

Is this a Cursor extension?

No. Aestheria is a design context layer, not a plugin: an MCP endpoint and a set of files. The same context serves Cursor, Claude Code, Copilot, Codex, and anything else that reads a repository or speaks MCP, so switching editors costs you nothing.

What stops Cursor from ignoring it?

Nothing enforces a prompt, which is why the layer ships verification as well as content. `validate_snippet` checks generated markup against the system and returns the specific violations, so an agent can correct itself before the diff reaches you, and a hook or a pre-delivery step can make that check non-optional.

Can I edit the system?

Yes. It is starter context, not a black box: every token, component, and rule is yours to change, and your edits are what the agent then generates against. Pin a version and the system holds still; move it and every consumer moves together.