design-system-mcp

Overview Schema Source Related Servers Discussions Admin

Get a component contract

get_component

Read-onlyIdempotent

Retrieve a component’s full contract—import, props, variants, tokens, parts, and docs—before using it so UI matches the design system. Use the component name or file path in a monorepo.

Instructions

Get the full contract of one component: import, props with types and defaults, cva variants and the classes each applies, parts (sub-components), design tokens it uses, usage guidelines and examples from its docs. Call it before using a component. Accepts "Button", "CardHeader" or "Card.Header". At a monorepo root, pass path (the file you are editing) to get the component its project uses.

Input Schema

Name	Required	Description	Default
`name`	Yes	Component name, e.g. "Button" or "CardHeader".
`path`	No	In a monorepo served from its root: the file you are editing, or a project folder, relative to the root, to answer from that project. Without it, every project is listed together. Ignored in a single project.

Output Schema

Name	Required	Description
`docs`	No
`name`	Yes	How the component is written in JSX: Button, CardHeader, Tabs.List.
`props`	Yes
`import`	Yes	The import statement to use.
`parent`	No
`source`	Yes
`tokens`	Yes	Names of the design tokens its classes use.
`aliases`	Yes
`cssVars`	Yes
`element`	No	The native element it renders or wraps.
`package`	No	At a workspace root: the package its source belongs to, e.g. "@acme/ui".
`examples`	Yes
`inherits`	Yes
`projects`	No	At a workspace root: the folders of the projects that use it.
`variants`	Yes
`openProps`	Yes	Part of the props type did not resolve; extra props may be accepted.
`classNames`	Yes
`deprecated`	No
`exportName`	Yes
`importPath`	Yes
`description`	No
`subcomponents`	Yes
`compoundVariants`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.0Oct 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/closed-world/no-destruction, so safety is covered. The description adds context the annotations cannot: that it accepts dotted names like 'Card.Header', and that at a monorepo root omitting `path` merges every project's answer. Those are real behavioral traits affecting how the agent calls it.

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

Conciseness4/5

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

Dense but front-loaded: the returned contract is listed first, then the usage trigger, then name formats, then monorepo behavior. Nearly every clause earns its place, though the single unstructured paragraph is a bit heavy for the amount of information packed into it.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, yet the description still previews what the contract contains. With 100% parameter coverage and annotations covering the safety profile, an agent has everything needed to call this correctly.

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?

Schema coverage is 100% and the `path` parameter is already well documented, so the baseline would be 3. The description adds genuine meaning beyond the schema by disclosing that `Card.Header` is an acceptable `name` form (the schema only shows 'Button'/'CardHeader') and by restating the project-scoping semantics of `path`.

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?

States a specific verb+resource ('Get the full contract of one component') and then enumerates the contract contents: import, typed props with defaults, cva variants and applied classes, parts, tokens, guidelines and examples. This clearly separates it from the sibling list_components and search_components, which cannot return a full single-component contract.

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

Usage Guidelines4/5

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

'Call it before using a component' gives an explicit trigger condition, and the monorepo `path` sentence explains the situation in which the extra argument is needed. It does not explicitly name list_components/search_components as the alternatives, but the single-vs-many distinction is unambiguous from the purpose sentence.

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

Deploy Server