Which integrations are available for this server?

Manages variant manifests, design token mappings, and structural contracts between Figma and code, enabling variant lifecycle management and diff classification. Provides accessibility contracts, composition patterns, keyboard interactions, and caveats for Radix UI primitives to ensure accessible component composition.

How do I use component-contracts?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@component-contracts Show me the accessibility contract for Dialog" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

component-contracts

by jeremysykes

Overview Schema Related Servers Score Discussions

TypeScript

Local

component-contracts

Two MCP servers that form the authority layer for design-to-code component lifecycles.

Overview

Variant Authority is the engineering contract for your component library. It defines what variants exist on a component, what slots are required, how design tokens map between Figma and code, and what happens when a component is deprecated. When a variant surface changes, it classifies the diff as major, minor, or patch so consumers know the impact before shipping.

Radix Primitives is the accessibility foundation. It maps component types to Radix UI primitives, exposes the ARIA contracts and keyboard interactions that come free with each primitive, and documents known caveats and workarounds. Together, these two servers are the source of truth that d2c operates on -- one for structural correctness, the other for accessible composition.

Related MCP server: ds-pilot

Tool surface

Variant Authority (5 tools)

Tool	Description
`get_manifest(component)`	Returns the full variant manifest
`set_manifest(component, manifest)`	Writes or updates a manifest, validates with `isVariantManifest()`
`get_usage(component)`	Scans workspace for files importing the component
`diff_manifests(component, before, after)`	Classifies changes as major/minor/patch
`validate_usage(component, props)`	Validates variant values and required slots

Radix Primitives (4 tools)

Tool	Description
`get_primitive(name)`	Returns accessibility contract, composition pattern, caveats
`get_composition_pattern(component)`	Maps a component type to its Radix primitive
`get_caveats(primitive)`	Returns known issues and workarounds
`list_primitives()`	Enumerates all 16 available primitives

VariantManifest schema

interface VariantManifest {
  component: string;
  version: string;
  figmaFileKey: string;
  figmaNodeId: string;
  variants: Record<string, VariantDefinition>;
  slots: SlotDefinition[];
  tokens: Record<string, TokenBinding>;
  authority: AuthorityMap;
  deprecated?: DeprecationInfo;
  semanticTokenFile?: string;
  createdAt: string;
  updatedAt: string;
}

interface VariantDefinition {
  values: string[];
  defaultValue: string;
  type: "string" | "boolean" | "number";
  description?: string;
}

interface SlotDefinition {
  name: string;
  required: boolean;
  description?: string;
}

interface TokenBinding {
  figmaValue: string;
  codeValue: string;
  dtcgPath: string;
  category: "color" | "spacing" | "typography" | "border" | "shadow" | "opacity";
}

interface AuthorityMap {
  structure: "figma" | "cva";
  visual: "figma" | "cva";
  conflictStrategy: "escalate" | "figma-wins" | "cva-wins";
}

interface DeprecationInfo {
  deprecated: true;
  replacedBy: string;
  migrationGuide: string;
  deprecatedAt: string;
  removalTarget?: string;
}

PrimitiveCapability schema

interface PrimitiveCapability {
  name: string;
  radixPackage: string | null;
  vuePackage: string | null;
  accessibilityContract: {
    role: string;
    keyboardInteractions: string[];
    ariaAttributes: string[];
  };
  compositionPattern: string;
  caveats: string[];
  recommendedFor: string[];
  avoidFor: string[];
  version: string;
}

Installation

Claude Code

claude mcp add variant-authority -- npx tsx src/variant-authority/server.ts
claude mcp add radix-primitives -- npx tsx src/radix-primitives/server.ts

Cursor

In .cursor/mcp.json:

{
  "mcpServers": {
    "variant-authority": {
      "command": "npx",
      "args": ["tsx", "src/variant-authority/server.ts"]
    },
    "radix-primitives": {
      "command": "npx",
      "args": ["tsx", "src/radix-primitives/server.ts"]
    }
  }
}

Codex CLI

codex mcp add variant-authority -- npx tsx src/variant-authority/server.ts
codex mcp add radix-primitives -- npx tsx src/radix-primitives/server.ts

Development

npm scripts

Script	Purpose
`npm run build`	Compile TypeScript with `tsc`
`npm test`	Run tests with Vitest
`npm run dev:va`	Start variant-authority server in dev mode
`npm run dev:rp`	Start radix-primitives server in dev mode

Project structure

component-contracts/
  src/
    variant-authority/
      server.ts             MCP server entry point
      registry.ts           JSON registry read/write
    radix-primitives/
      server.ts             MCP server entry point
      capability-map.ts     Static primitive data
    shared/
      schemas.ts            TypeScript interfaces + validation
      errors.ts             Shared error types
  dist/                     Compiled output
  .variant-authority/       Registry storage (gitignored in consuming repos)

Relationship to d2c

component-contracts provides the authority layer. d2c provides the lifecycle operator. During its phases, d2c calls these MCP servers to read and write variant manifests, query primitive mappings, and validate component usage. The two packages are designed to work together but can be used independently -- any tooling that needs a persistent variant registry or a Radix capability map can consume these servers directly.

License

MIT

Available Tools

4 tools

get_caveatsA

Returns known issues, workarounds, and version-specific behavior for a Radix primitive.

ParametersJSON Schema

Name	Required	Description	Default
`primitive`	Yes	The primitive name (e.g. Dialog, Select)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It clearly frames the operation as non-mutating information retrieval ('Returns...') and specifies the content categories returned. It does not describe error behavior for unknown primitives, but for a one-parameter read-only lookup this is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and output categories, with no filler or repetition of schema information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one fully documented parameter and no output schema, the description conveys the return content adequately. It lacks explicit alternatives or edge-case behavior, but the tool is simple enough that an agent can call it correctly with the provided information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the sole parameter with an example ('e.g. Dialog, Select'), and the description adds no further detail about expected values or constraints beyond the word 'Radix'. With 100% schema coverage, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Returns') and a concrete resource ('known issues, workarounds, and version-specific behavior for a Radix primitive'), which clearly differentiates it from sibling tools like list_primitives or get_primitive. An agent can tell immediately what this tool is for without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when caveats or version quirks are needed, but it gives no explicit guidance on when to prefer this over get_primitive or get_composition_pattern. There are no stated exclusions or alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_composition_patternA

Returns the recommended Radix primitive(s) and composition pattern for a given component type.

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes	The component type to look up (e.g. Modal, Badge, DatePicker)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only lookup that returns advisory output, but it does not cover error behavior for unknown component types, case sensitivity, or whether the result is guaranteed to exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with no filler. It front-loads the core behavior and remains complete without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool, the description tells the agent what input to supply and what kind of output to expect. The main gap is the lack of detail about the exact shape or content of the composition pattern, but the tool's complexity is low enough that this is not a critical omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the single parameter with a clear description and example. The tool description adds no additional parameter meaning, which is acceptable since the schema already documents the component argument adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') and names the exact resource ('recommended Radix primitive(s) and composition pattern') for a given component type. This makes the tool's purpose immediately clear and distinguishes it from siblings like get_primitive or list_primitives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when an agent needs recommended primitives and a composition pattern for a component type. However, it does not explicitly mention when to prefer get_primitive or list_primitives, nor does it state any exclusions or alternative conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_primitiveB

Returns the primitive API, accessibility contract, composition pattern, and known caveats for a Radix UI primitive.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The primitive name (e.g. Dialog, Select, Tooltip)

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full transparency burden. It tells the agent the tool 'returns' a composite of four content categories, which clarifies the basic read behavior. However, it does not disclose behavior on errors, invalid primitive names, or whether results are fetched live or cached, which are relevant for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately states the return value and scope. Every word contributes meaning, and there is no filler or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter getter, the description covers the input and the high-level content of the output. But with no output schema and no annotations, it omits details about the output shape, failure modes, and the relationship to the overlapping sibling tools. The presence of siblings like get_caveats and get_composition_pattern makes the absence of distinction a real completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the only parameter 'name' with examples like Dialog, Select, and Tooltip, and the description adds the 'Radix UI primitive' context. With 100% schema description coverage, the description does not need to add much, and it does not provide any additional constraint or format detail. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'returns' a specific resource: the primitive API, accessibility contract, composition pattern, and known caveats for a Radix UI primitive. This is a specific verb-plus-resource formulation that makes the core purpose understandable. However, it does not distinguish itself from sibling tools like get_composition_pattern and get_caveats, which appear to overlap with the returned content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use get_primitive versus list_primitives, get_composition_pattern, or get_caveats. The description does not explain whether this tool is an aggregate, a convenience wrapper, or intended for a different use case. An agent is left to infer the relationship from sibling names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_primitivesA

Returns all available Radix primitives with a one-line description.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosing behavior. It states both the operation and the output shape: a list of all primitives, each with a one-line description. For a simple zero-parameter enumeration tool, this is sufficiently transparent, though it does not mention ordering, pagination, or exact return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. It front-loads the verb and resource, then adds the only important output detail: the one-line description per primitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with no output schema and no annotations, the description gives enough information for an agent to know what it will get and when to call it. It could optionally mention whether results are sorted or paginated, but for this simple enumeration tool that is not a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to explain about parameter meaning. The input schema fully covers the input surface, and the description appropriately describes an input-free operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific verb and resource: it 'Returns all available Radix primitives'. The phrase 'all available' plus 'with a one-line description' distinguishes it from the sibling tool get_primitive, which presumably fetches a single primitive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the tool to use when you need an overall list of Radix primitives, but it does not explicitly say when to use it instead of get_primitive, get_composition_pattern, or get_caveats. Usage context is mostly inferred from the word 'all' rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation3/5

get_primitive overlaps with get_composition_pattern and get_caveats since it already returns composition patterns and caveats. However, get_composition_pattern is scoped to component types rather than primitives, and get_caveats is more targeted, so descriptions help somewhat, but the boundaries remain fuzzy.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: list_primitives uses 'list' and the others use 'get', which is a predictable and uniform convention. There are no mixed styles or ambiguous verbs.

Tool Count4/5

Four tools is a reasonable size for a focused server, but two of them (get_composition_pattern, get_caveats) largely duplicate what get_primitive already provides, so the count feels slightly padded rather than perfectly lean.

Completeness4/5

The set covers listing primitives and retrieving detailed contract information, which serves the stated purpose. A minor gap is the lack of a dedicated tool for just the API or accessibility contract, but get_primitive essentially covers this in aggregate, so no critical dead ends exist.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Supernova
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1
mzizi-mcp A
io.github.nyuchi
Read-only MCP over the Mzizi design system registry — nodes, components, ownership.
Design Tools Developer Tools
2
Figma MCP ServerOAuth
com.figma.mcp
The Figma MCP server brings Figma design context directly into your AI workflow.
Developer Tools Content Management Systems
31,921
AgentLux B
io.github.agentlux
Hosted AgentLux MCP server for marketplace, identity, creator, services, and social flows.
Agent Orchestration Autonomous Agents Social Media
7921

Related MCP Servers

memoire
Design Tools Developer Tools
memi-design
A
license
A
quality
B
maintenance
Design system MCP server. 20 tools: extract design tokens from any URL, pull from Figma or Penpot, generate React + shadcn/ui components from specs, run WCAG audits, sync tokens bidirectionally.
Updated a month ago (2026-08-08 17:25 UTC)
50
276
39
MIT
ds-pilot
Design Tools Developer Tools
lyse-labs
A
license
Not graded
quality
C
maintenance
MCP server that exposes your design system components and tokens to AI agents, preventing duplicate component creation and hardcoded token values.
Updated 4 months ago (2026-05-13 14:09 UTC)
18
9
MIT
ds-mcp
Developer Tools Design Tools
aestheticfunction
A
license
Not graded
quality
A
maintenance
A read-only MCP server that provides AI coding agents with a queryable contract for design system tokens, components, patterns, and anti-patterns.
Updated 22 days ago (2026-08-12 17:25 UTC)
20
1
Apache 2.0
UI Toolkit MCP Server
Design Tools Developer Tools Testing & QA Tools
elsahafy
A
license
Not graded
quality
F
maintenance
Comprehensive MCP server for end-to-end UI development, offering tools to generate components, manage design tokens, audit accessibility, autofix issues, inspect live pages, compare screenshots, and more across multiple frameworks.
Updated 2 months ago (2026-06-24 07:23 UTC)
20
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeremysykes/component-contracts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server