MCP server

The server speaks MCP over streamable HTTP at /mcp - one POST endpoint with JSON-RPC in the body. Every tool is also a plain GET under /api/mcp/..., which is what makes each of them inspectable from a browser address bar. Both URLs below are this deployment's own.

Register the server

.vscode/mcp.json - VS Code and GitHub Copilot:

{
  "servers": {
    "bitBlazorUI": {
      "type": "http",
      "url": "https://blazorui.bitplatform.dev/mcp"
    }
  }
}

mcp.json - Cursor, Claude, Windsurf and anything else that speaks MCP:

{
  "mcpServers": {
    "bitBlazorUI": {
      "type": "http",
      "url": "https://blazorui.bitplatform.dev/mcp"
    }
  }
}

Tell the agent to use it

Add these rules to your agents.md, copilot-instructions.md, .cursor/rules, or whatever your agent reads. Most of what an agent needs to know is already in the server's own instructions - see the handshake below - so these say only which server to prefer and when.

### bit BlazorUI

- For all UI work in this Blazor project, you **MUST** use the bit BlazorUI MCP server.
- Start with `SearchBitBlazorUI`: this library's name for a thing is often not the one the task
  suggests (a select is `BitDropdown`, a toast is `BitSnackBar`, a skeleton is `BitShimmer`).
- Before writing markup, call `GetBitBlazorUIComponent` for every component you are about to use,
  and `GetBitBlazorUIComponentExamples` for the working code of anything non-obvious.
- Prefer `Bit*` components over plain HTML/CSS or another UI library.

The client states the protocol version it speaks and what it supports; the server answers with the same for itself. Each capability comes back as an empty object, which is the protocol working as intended: the key's presence is the declaration, and what goes inside is only the optional extras. A capability a server does not have is absent, not empty. Nothing here hands back a session id - streamable HTTP is stateless, so every request stands on its own and any replica can answer it. The client then sends an initialized notification, which takes no id and gets no result back. This page does both automatically when it loads.

POST https://blazorui.bitplatform.dev/mcp
Content-Type: application/json
Accept: application/json, text/event-stream

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": { "name": "bit-blazorui-docs", "version": "1.0" }
  }
}

Connecting...

Every tool comes back with its name, the description the model reads to decide whether to call it, a JSON Schema for its arguments, and its annotations. There are seven, and the count is the design rather than what was left over: a tool's description is paid for in every request of every session, so a listing is not a tool here - it is what a retrieval tool answers when it is called with no argument.

Nothing sent yet.

The response pane shows the JSON-RPC envelope the client receives; the pane under it shows the text inside it, which is what an agent would actually put in front of the model. Try SearchBitBlazorUI with a screen described in your own words, or GetBitBlazorUIComponent with the name of another library's component - Select, Toast, Skeleton all resolve. Three of the seven take no required argument: send GetBitBlazorUIComponent with an empty object and the whole catalog comes back instead of one component.

Nothing sent yet.

A prompt is a workflow a client lists as a slash command; each of these five spends its words on the order to call the tools in, because the failure mode of an agent here is not ignorance - it is writing markup from a remembered API before it has read the current one. A resource is a document addressed by URI, for a client that wants to attach documentation up front or let someone browse it. Both read the same catalogs the tools do, so neither can go stale relative to the other. resources/list deliberately leaves out the parameterised ones: a template is not a document, it is the shape of the URIs that address a family of them.

Nothing sent yet.

Every prompt argument and every template placeholder on this server is drawn from a closed set it already holds, so completion/complete can answer with the values that are valid for one argument, filtered by what has been typed so far. Type below and watch the request go out on each keystroke - which is exactly how an editor's picker uses it. Prefix matches come first, then anything containing what was typed.

Nothing sent yet.

The MCP methods are ordinary controller actions, so each one is also reachable as GET /api/mcp/{tool}. That is the quickest way to see what a tool answers - and it is what makes this server inspectable by anything that can fetch a URL, including a shell script and a browser address bar.

Nothing sent yet.

How it stays true

Nothing on this server is written down twice. The site's own navigation decides which components exist and what they are also called; the loaded assemblies decide which package each one ships in and what it is generic over; the demo pages carry the hand-written parameter tables and the worked examples; the XML documentation compiled beside the library carries everything else. Adding a component to the nav is all it takes for it to appear in the catalog, in the search index and in the completions above - so the tools cannot describe a version of bit BlazorUI that this deployment is not running.