Editor and MCP

What MCP is#

The Model Context Protocol is an open standard for connecting assistants to tools and data through a declared interface. A server publishes its operations and the shape of their inputs and outputs. A client (an editor, an agent or a chat interface) discovers those operations when it connects and calls them while it works.

Without MCP, context is pushed to the model: someone pastes documentation into a prompt, and the model works from whatever fits in that window. With MCP, the model requests context when it needs it, as structured data it does not have to extract from prose.

MCP is an open protocol, not a vendor's plugin format, so one server works with every compatible client. You do not need a separate extension for each editor.

The problem it solves#

Ask an assistant for a date picker and it will write one. The code usually looks correct: a plausible import path, sensibly named props and a variant that a design system might have. It often fails to compile, because none of those details came from your library. They were predicted from many similar libraries.

A better prompt does not fix this. A prop that is common in similar libraries is a likely prediction whether or not your version has it, and the model cannot tell the difference. The model answers from a fixed training snapshot, and your component API is not in it.

Design systems suit MCP well because most of what an assistant needs is already machine-readable. Props are defined as types. Variants are a finite set. Tokens live in configuration. The server needs nothing the library does not already define.

What a server exposes#

A server exposes the parts that can be checked. A component's props and their types, so an invented prop is rejected before build time. Its variants, so a value outside the set fails immediately. The design tokens behind it, so a generated screen uses the brand values instead of hard-coded hex codes. Its accessibility requirements, such as which elements need a label and what the keyboard must reach, because generated components most often omit these.

Versions matter too. A question about a library is a question about a library at a specific version. A server answers for the version you have installed, not the release that was current when the model was trained.

Connecting an editor#

The server runs at https://mcp.orvain.dev and takes the licence key from your purchase as a bearer token. In Cursor, add one entry to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "orvain": {
      "url": "https://mcp.orvain.dev",
      "headers": {
        "Authorization": "Bearer <your-licence-key>"
      }
    }
  }
}

In Claude Code, run one command:

$ claude mcp add --transport http orvain https://mcp.orvain.dev --header "Authorization: Bearer <your-licence-key>"

What it will not do#

It does not make an assistant good at design. A server can report that a component takes a size prop with three values. It cannot tell you which one suits the page you are building. Layout, hierarchy and other design decisions remain yours.

It does not replace code review. Output validated against the schema uses only props and imports that exist. That does not mean the code is correct.

It does not replace documentation for people. People need to know why and when to use a component. Agents need its exact API. This page serves the first need, and the server serves the second.

Questions#