MCP tools & resources

Overview

The server exposes twelve tools and four resources. Tools: `get_capabilities` (what Inkbridge does, a summary of your loaded model, and how to use the server — start here); `list_components` (every component with its kind, variant axes, and stories); `get_component` (the full resolved definition for one component — classes, variants, states; pass `includeJsxTree` for the raw tree); `get_tokens` (your design tokens — `view: "consumer"` for consumer-authored only, or `view: "full"` for the merged map, plus `theme` for a named theme's effective values); `check_conformance` (verify generated code against the model — invented palette colors, hardcoded color values, off-scale radii, token reuse, CVA convention — for Tailwind classes AND MUI sx color refs); `suggest_token` (the nearest existing token for a raw color or dimension — the fix half of check_conformance); `check_story` (verify a story follows the authoring conventions — meta.title, one story per state, fixed-width wrapper); `draft_component` (scaffold a shadcn/CVA component + one-story-per-variant story as text); `write_component` (write a conformant component + story to your working tree — each file gated by check_conformance / check_story, all-or-nothing; you review and commit, which closes the loop); `diagnose_component` (story-readiness of an existing, possibly coupled component — names the form/store/data-fetching/motion couplings, proposes the states worth storying, and verdicts decorator vs presentational extraction — the brownfield onboarding step); `diff_model` (what changed since your last check — components added/changed/removed and whether tokens changed); `scan` (regenerate the model by running the scanner headlessly — refresh after the code changed; the server also auto-scans on first use). Resources: `inkbridge://components`, `inkbridge://tokens`, `inkbridge://guide/readme` (the public README), and `inkbridge://guide/authoring` (the authoring contract — how to write components the scanner can model). Internal plugin docs are never exposed.

The typical loop: list_components → get_component + get_tokens → generate (or draft_component to start) → check_conformance → fix with suggest_token → write_component → present. The server pushes this workflow to the agent at connect time via its instructions, so plain-language requests follow it without manual tool calls.

Who calls these — and what you do

You never call these tools yourself. Your only setup is having the server registered — the starters ship a committed .mcp.json and inkbridge setup writes one — then you ask your agent for UI in plain language. Three layers make the agent use the model, in increasing order of guidance:

1. 1

   Server instructions — delivered to every MCP-capable agent at connect time. They say: consult the design system before generating UI, never invent palette colors, verify with check_conformance before presenting. Works with zero further setup, in any agent.

2. 2

   The authoring contract — inkbridge://guide/authoring, an agent-neutral resource the instructions point to: token use, one story per state, the statically-analyzable styling subset, and the self-check step.

3. 3

   The agent skills (install with inkbridge skill install): inkbridge-component-authoring auto-activates when you bootstrap a component from a Figma frame — Figma MCP supplies the design, this server supplies what your code already has; inkbridge-build-components guides building or porting components in Inkbridge projects. Both make check_conformance the first validation step, before Storybook or typecheck.

Tool reference

check_conformance in depth

The checker gathers every class token from the source's string literals and validates each one against the model's vocabulary. Zero violations is the bar — everything else in the report is context.

The rules

The report

Example report

{
  "conforms": false,
  "violations": [
    "bg-green-500 (invented Tailwind palette color)",
    "text-[#1a1a2e] (hardcoded color value)"
  ],
  "tokensReused": ["card", "muted-foreground", "primary"],
  "radiusUsed": ["lg"],
  "unrecognized": [],
  "cva": { "present": true, "hasVariantAxis": true, "hasDefaultVariants": true },
  "followsCvaConvention": true,
  "notes": [],
  "summary": "Does not conform: 2 violation(s) — see `violations`."
}

Scope: the checker covers Tailwind class usage and MUI sx color refs (invented palette refs and hardcoded colors in sx). It doesn’t police MUI spacing — that’s legitimately an arbitrary multiplier — and a source with no strings to read says so in notes rather than passing silently.

Resources

Internal plugin implementation docs are never exposed — the doc surface is consumer-public only.

Trust model

The server is read-only toward your code and runs locally over stdio — nothing is hosted, and no source leaves your machine. The only thing it writes is its own model file (.inkbridge/component-definitions.json, gitignored) when scanning. check_conformance's path input is guarded to the project root, and the doc resources serve public files only. Same trust model as the dev-only scan route the Figma plugin uses.

Troubleshooting

Quick reference

1. 1

   `get_capabilities` — orient: what Inkbridge does plus your project's loaded model summary.

2. 2

   `list_components` — list every component with kind, variant axes, and stories.

3. 3

   `get_component { name }` — full resolved definition; add `includeJsxTree: true` for the raw JSX.

4. 4

   `get_tokens { view, theme }` — "consumer" (default) or "full" token map; pass a `theme` name for its effective values.

5. 5

   `check_conformance { code | path }` — verify generated code (Tailwind classes + MUI sx) before presenting it; fix every violation it reports.

6. 6

   `suggest_token { value }` — when a value is flagged, get the nearest real token to use instead (fix, don't guess).

7. 7

   `check_story { code | path }` — verify a story follows the authoring conventions before presenting it.

8. 8

   `draft_component { name, basedOn }` — get a correct-by-construction CVA scaffold to start from, then fill the class slots.

9. 9

   `write_component { files }` — write the conformant component + story to your working tree (gated by check_conformance / check_story); review the diff and commit.

10. 10

    `diagnose_component { path }` — for an existing coupled component (forms/store/motion), learn what blocks storying it: the couplings, the states worth storying, and decorator vs extraction.

11. 11

    `diff_model` — what changed since your last call (baseline on first use); good for summarising a change set.

12. 12

    `scan` — regenerate the model after code changes (auto-runs on first use if the model is missing).

Related

• Read your design system from an AI agent (MCP)
• React Component Scanning