A
licenseNot graded
qualityB
maintenanceProvides design systems, UI prompts, and layout variation guidance to AI coding tools for generating better user interfaces.
268 npm
2,163
MIT
Open Components
by com.uxfront
Server Details
Guidelines for UI components with a perfect UX, DX and AX, whether humans or AI agents write them.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- uxfront-com/open-components
- GitHub Stars
- 7
TDQS
A4.5/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a distinct artifact: contracts (get-contract), prose docs (get-page), code (get-reference-implementation), the catalog (list-components), rule records (list-rules) and discovery (search-docs). The descriptions explicitly resolve the one apparent overlap — get-contract carries rules too, but list-rules is scoped for filtering by ID/scope/level — with WHEN TO USE / WHEN NOT TO USE blocks that redirect to the right sibling tool.
Naming Consistency5/5
All six names follow a strict kebab-case verb_noun pattern: get-contract, get-page, get-reference-implementation, list-components, list-rules, search-docs. The verbs are also semantically consistent (get = fetch one artifact, list = enumerate, search = discover).
Tool Count5/5
Six tools is well within the sweet spot and every one covers a different retrieval mode (catalog, contract, prose, code, rules, search). Nothing feels redundant or like it could be merged without losing a distinct access path.
Completeness4/5
The read-only surface covers the domain end to end: discover components/foundations/roadmap, fetch contracts, drill into rules, read reasoning and examples, and pull reference code. Minor gaps: no tool to validate a component against its checklist (rules only say how a human/tool can check), and tokens are reachable only via get-contract rather than as a first-class query.
Available Tools
6 toolsget-contractGet ContractARead-onlyIdempotentInspect
Returns the contract of a component or a foundation, as YAML: its API (props, slots and events), its DOM contract (element, role, states, keyboard and parts), its tokens, and every rule in its checklist, each with a stable ID (like button/keep-focus), a level (must or should), a scope (component, usage or both) and how to check it. It holds every requirement in a fraction of the page's length, and it's the same file as https://opencomponents.dev/raw/docs/.yaml.
WHEN TO USE: first, before you build, review or explain a component or its tokens. WHEN NOT TO USE: for some of the rules only (by scope, layer, level or check), use list-rules. For the reasoning or the examples behind a rule, use get-page with its sections.
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | The component or foundation, like button or design-tokens. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description still adds real value beyond them: the return format is YAML, the payload is far shorter than the equivalent page, and the result is identical to the raw file at https://opencomponents.dev/raw/docs/<path>.yaml, which lets an agent reason about caching and provenance. It stops short of describing failure behavior for a bad component id, so not a 5.
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?
Front-loads what is returned, then the size/URL equivalence, then the use and do-not-use conditions as labeled blocks. The first sentence is long but every clause names a distinct part of the payload; no sentence is filler.
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?
No output schema exists, so the description carries the full burden of explaining the return value — and it does, enumerating the YAML sections and the shape of each checklist rule (id, level, scope, check). For a single-parameter read with a closed enum, nothing an agent needs to call it correctly is missing.
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?
There is a single parameter with 100% schema description coverage and an enum of all 14 valid values, so the schema already does the heavy lifting and the baseline is 3. The description adds only indirect hints — that a component maps to a docs path and to ID prefixes like button/keep-focus — without documenting the parameter itself.
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 and resource (returns the contract of a component or foundation) and enumerates the contents concretely: API, DOM contract, tokens, and checklist rules with stable IDs, levels and scopes. The sibling distinction is explicit — list-rules handles rule subsets and get-page handles reasoning/examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit WHEN TO USE ('first, before you build, review or explain') and a WHEN NOT TO USE that names two alternatives (list-rules, get-page) along with the exact conditions that select each one. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-pageGet PageARead-onlyIdempotentInspect
Reads a docs page as markdown, whole or just the sections you name. Component pages explain why each rule exists, with examples in React, Vue, Svelte, Angular, Solid, Astro and Vanilla: pass a framework to keep only its examples.
WHEN TO USE: for the reasoning, an example or the details behind a rule (like the sections ["Loading"] of the button's page), or for a page without a contract, like the introduction or the roadmap. WHEN NOT TO USE: for the requirements alone, use get-contract or list-rules, which are much shorter. To find which page or section covers a topic, use search-docs.
A page longer than about 8,000 tokens, like the button's, returns its outline instead: every heading with its anchor and length, so you can ask for the sections you need. So do sections that are too long to return together.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, field, input, popover, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section. | |
| sections | No | The sections to read, by heading or anchor, like ["Loading"] or ["#ux-rules"]. Each comes with its sub-sections. Name a parent to tell apart headings that repeat, as in "Every state > Loading". | |
| framework | No | Your framework, to keep only its examples. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds substantive behavior beyond them: pages over ~8,000 tokens return an outline with headings, anchors, and lengths instead of content, and oversized sections are likewise elided. That truncation behavior is exactly the kind of non-obvious trait an agent needs before calling.
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?
Front-loaded with the core capability, then organized into WHEN TO USE / WHEN NOT TO USE, then the truncation caveat. Every sentence carries routing or behavioral information; no filler.
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?
With no output schema, the description still explains the shape of the return (markdown content vs. outline fallback) and the framework-filtered view, which is what an agent needs to interpret results. Nothing material is missing for a 3-parameter read tool.
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?
Schema description coverage is 100%, so path, sections, and framework are already well documented, including anchor syntax and parent>child disambiguation. The description only restates the framework-filter purpose and the section-naming pattern, adding little beyond the schema; baseline 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?
States a specific verb and resource ('Reads a docs page as markdown') plus the two scoping modes (whole page or named sections) and the framework filter. It is immediately distinguishable from get-contract, list-rules, and search-docs, which are named in the same breath.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit WHEN TO USE and WHEN NOT TO USE blocks that name the alternatives (get-contract, list-rules, search-docs) and the exact condition that selects each. Nothing about routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-reference-implementationGet Reference ImplementationARead-onlyIdempotentInspect
Returns a shipped component's reference implementation: a Vue 3 component that meets every rule in its checklist, the tests that prove it, the helpers it shares with other components and its theme tokens. The live examples on the site run on this code.
WHEN TO USE: to build a component that meets the standard, in Vue or by porting it and its tests to another framework, or to see how a rule is met in code. WHEN NOT TO USE: for the requirements, use get-contract. For how the component is used in another framework, use get-page with that framework.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Only these files, like ["Button.vue"] or ["Button.test.ts"]. Leave it out for every file. | |
| component | Yes | A component with a reference implementation, like button. |
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, non-destructive and closed-world, so the safety profile is covered; the description contributes the substantive detail that the returned code is the same code powering the live site examples, which tells the agent the output is authoritative and executable. It does not warn about payload size or that the optional files filter is the way to narrow an otherwise multi-file response, which is the one behavioral gap left.
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?
Front-loaded claim of what is returned, followed by two labeled routing blocks. Every sentence carries information and the WHEN NOT TO USE lines do double duty by naming siblings.
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?
With no output schema, the description does the necessary work of describing the return bundle, and it covers routing for a two-parameter tool. The remaining gap is that it never signals response size or that files should be used to trim a large multi-file payload, which matters for a tool that returns whole component trees plus tests.
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?
Schema description coverage is 100%, including a clear enum for component and a documented files filter, so the schema carries parameter meaning. The description's mention of "helpers it shares with other components and its theme tokens" implies a multi-file bundle, but it adds no explicit guidance on the files parameter beyond what the schema already says. Baseline 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?
States a specific verb and resource ("Returns a shipped component's reference implementation") and then enumerates exactly what the payload contains: the Vue 3 component, its proving tests, shared helpers, and theme tokens. This is clearly distinguishable from get-contract (rules) and get-page (other frameworks) named in the same description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE / WHEN NOT TO USE blocks name the alternative tools and the exact condition that routes to each: requirements go to get-contract, other-framework usage goes to get-page. An agent can select correctly without inspecting any schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-componentsList ComponentsARead-onlyIdempotentInspect
Lists what the Open Components standard covers: the components that have shipped (like Button), the foundations every component follows (like Design Tokens), and the components planned on the Roadmap.
WHEN TO USE: to check whether a component has a standard yet, to get the name the other tools take for it, or to see what's planned. WHEN NOT TO USE: if you already know the component, call get-contract directly. To find a topic in the docs, use search-docs.
Shipped entries come with their page, their contract and how many rules they have. Planned ones have no page, contract or rules yet: hold them to the three layers and Design Tokens, following the Button's structure, as the build-component prompt does.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Which components to list. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| components | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the data semantics: shipped entries carry page, contract and rule counts while planned ones have none. That distinction materially affects how an agent interprets the response. It stops short of discussing pagination or ordering, but the behavioral gap is small.
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?
Front-loaded with purpose, then cleanly separated WHEN TO USE / WHEN NOT TO USE blocks, which is well suited to scanning. The closing paragraph about planned entries is slightly dense and mixes return-shape detail with build guidance, but nothing is wasted.
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?
With an output schema present, the description need not enumerate return fields, and it correctly focuses on when to call it, what the two entry types mean, and which sibling to prefer. Complete enough for correct invocation; only minor gaps around ordering or result size remain.
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 single status parameter is fully documented in the schema with an enum and default, so the baseline is 3. The description reinforces the shipped/planned dichotomy that the enum encodes but adds no syntax, default behavior, or filtering nuance beyond what the schema already states.
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 and resource (lists components of the Open Components standard) and breaks the scope into three concrete categories: shipped, foundations, and planned/Roadmap. The agent can distinguish it from get-contract and search-docs without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE (check whether a component has a standard, get the name other tools use, see what's planned) and WHEN NOT TO USE (use get-contract if the component is known; use search-docs to find a doc topic). Both alternatives are named with the selecting condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-rulesList RulesARead-onlyIdempotentInspect
Lists checklist rules as records, filtered by component, ID, scope, layer, level or check. Each rule has a stable ID to cite in reviews and commits, its level (must or should), its scope, its requirement, how to check it (like a unit test, a review or axe's button-name rule) and a link to it.
WHEN TO USE: to review code rule by rule, to get only the rules that apply to a task, to look rules up by ID, or to find the ones a tool can check. Pass scope ["component", "both"] to build or review a component, and ["usage", "both"] to review a screen that uses it. WHEN NOT TO USE: for a component's API, DOM contract and tokens, use get-contract, which has every rule too.
It returns up to 50 rules at a time, and total counts every rule that matches. When there are more, pass nextOffset as offset, with the same filters, to get the next page.
A component meets the standard when it meets every must rule. Each should rule is expected unless there's a good reason not to follow it.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | The IDs of the rules to look up, like ["button/keep-focus"]. | |
| check | No | How the rule is checked. | |
| layer | No | ui (how it looks), ux (user experience), dx (developer experience) or ax (agentic experience). | |
| level | No | ||
| limit | No | How many rules to return, at most. | |
| scope | No | Who meets the rule: component (the component itself), usage (the code that uses it) or both. Rules without a scope, like the Design Tokens', match any scope. | |
| offset | No | Where the page starts: 0, or the nextOffset of the page before. | |
| automated | No | true for the rules tools check all of (unit tests, axe, a type check, a linter or a visual regression test), false for the ones a person checks, at least in part. | |
| component | No | The component or foundation, like button or design-tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rules | Yes | |
| total | Yes | How many rules match, on every page. |
| unknown | No | The IDs asked for that no rule has, with the ones that might have been meant. |
| nextOffset | No | The offset of the next page, when there is one. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on behavior they can't express: a 50-rule page cap, that `total` counts all matches, the exact pagination contract ('pass nextOffset as offset, with the same filters'), and the must/should compliance semantics for interpreting results.
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?
Strongly front-loaded: identity, then WHEN TO USE / WHEN NOT TO USE, then pagination, then semantics. Most sentences earn their place, though the sentence enumerating returned rule fields loses some value against an existing output schema and costs a bit of length.
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?
For a 9-parameter, fully optional, paginated list tool with an output schema and annotations, the description covers everything an agent still needs: filtering intent, pagination mechanics, scope choice, and how to interpret must versus should results.
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 high (89%), so the schema documents most parameters; the description adds selection guidance beyond it, notably which scope combinations to pass when building versus reviewing a screen. It doesn't cover every parameter (e.g. automated, layer) in prose, but the marginal value over the schema is real.
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 ('Lists checklist rules as records') plus the full set of filter dimensions, and explicitly disambiguates from get-contract ('for a component's API, DOM contract and tokens, use get-contract, which has every rule too'). An agent can select it 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE (rule-by-rule review, task-scoped rules, ID lookup, tool-checkable rules) and WHEN NOT TO USE naming the sibling to use instead. It even tells the agent which scope values to pass for the two most common review scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-docsSearch DocsARead-onlyIdempotentInspect
Searches the whole standard, every section of every page and every checklist rule, and returns the best matches: where each one is, a short excerpt, and for rules, their ID, level and scope.
WHEN TO USE: to find where a topic is covered when you don't know the page or the section, like "focus after delete", "spinner", "aria-pressed" or "dark mode". Then read a section with get-page, or rules with list-rules. WHEN NOT TO USE: to list a component's rules, use list-rules. To see which components there are, use list-components.
Search for a few specific words rather than a whole question.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Only search sections, or only rules. | |
| limit | No | How many results to return, at most. | |
| query | Yes | A few words, like "focus after delete" or "aria-pressed". | |
| component | No | Only search this page and its rules, like button or design-tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | How many sections and rules match, of which the best come first. |
| results | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so safety needs no restating. The description adds real behavioral texture: it says what a result contains (location, excerpt, and for rules ID/level/scope) and warns that short keyword queries outperform long natural-language questions. Return-shape detail is partly redundant with the output schema, which keeps this from a 5.
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?
Front-loaded with the core action, then cleanly partitioned into WHEN TO USE / WHEN NOT TO USE / a query tip. Every sentence carries actionable information; nothing is padding.
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?
For a 4-parameter, read-only search tool with an output schema and full annotation coverage, the description supplies everything an agent needs: scope, routing to siblings, follow-up reads, and query formulation guidance.
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?
Schema coverage is 100% and the enum-constrained filters (type, component) are fully self-documenting, so the schema carries the load. The description adds one useful hint on phrasing the query parameter ('a few specific words rather than a whole question'), but says nothing about limit or component scoping, so baseline 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?
States a specific verb and resource with full scope ('searches the whole standard, every section of every page and every checklist rule') plus a preview of the result shape. It is clearly distinguishable from get-page and list-rules, which read structured slices rather than doing free-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE and WHEN NOT TO USE blocks name the alternatives (get-page, list-rules, list-components) and the conditions that select them, backed by concrete example queries. It even specifies the follow-up path after a search, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "popover", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "field", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, popover, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, field, input, popover, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "checkbox-group", - "dialog", - "input", - "popover", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "checkbox-group", + "dialog", + "field", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "popover", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "field", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "popover", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "field", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, popover, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "checkbox-group", - "dialog", - "input", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "checkbox-group", + "dialog", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "radio-group", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "popover", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
4 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "radio-group", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, radio-group, button, card, checkbox-group, checkbox, dialog, input, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, radio-group, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "radio-group", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "radio-group", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "radio-group", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, radio-group, button, card, checkbox-group, checkbox, dialog, input, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "checkbox-group", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "checkbox-group", + "dialog", + "input", + "radio-group", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "radio-group", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "card", - "checkbox-group", - "checkbox", - "dialog", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "radio-group", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
4 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "dialog", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, dialog, switch, textarea, tooltip, checkbox-group), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, card, checkbox-group, checkbox, dialog, input, spinner, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "dialog", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "dialog", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "card", + "checkbox-group", + "checkbox", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "dialog", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, textarea, tooltip, checkbox-group), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, dialog, switch, textarea, tooltip, checkbox-group), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "checkbox-group", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "checkbox-group", + "dialog", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "dialog", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip", - "checkbox-group" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "dialog", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, textarea, tooltip, checkbox-group), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "input", - "spinner", - "switch", - "textarea", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "checkbox-group", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "textarea", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip", + "checkbox-group" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, textarea, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "card", - "checkbox", - "input", - "spinner", - "switch", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "input", + "spinner", + "switch", + "textarea", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "card", - "checkbox", - "switch", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "textarea", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "switch", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, switch, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, card, checkbox, switch, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "input", - "spinner", - "switch", - "tooltip" -]New value: +[ + "button", + "card", + "checkbox", + "input", + "spinner", + "switch", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "switch", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "switch", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "card", + "checkbox", + "switch", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "switch", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, switch, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "input", - "spinner", - "tooltip" -]New value: +[ + "button", + "input", + "spinner", + "switch", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input", - "tooltip" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "switch", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input", - "tooltip" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "switch", + "tooltip" +]
5 tool updates
- Changed
get-contract1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "tooltip" +]
- Changed
get-page1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."New value: +"The page: its name (introduction, roadmap, mcp-server, agent-plugin, design-tokens, button, spinner, input, tooltip), or its path, like /docs/components/button. A URL's #anchor, like the ones search-docs returns, reads that section."
- Changed
get-reference-implementation1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "button", - "input", - "spinner" -]New value: +[ + "button", + "input", + "spinner", + "tooltip" +]
- Changed
list-rules1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "design-tokens", - "button", - "spinner", - "input" -]New value: +[ + "design-tokens", + "button", + "spinner", + "input", + "tooltip" +]
- Changed
search-docs1 field changed- changed
Input schema / properties / component / enumPrevious value: -[ - "introduction", - "roadmap", - "mcp-server", - "agent-plugin", - "design-tokens", - "button", - "spinner", - "input" -]New value: +[ + "introduction", + "roadmap", + "mcp-server", + "agent-plugin", + "design-tokens", + "button", + "spinner", + "input", + "tooltip" +]
1 tool update
- Changed
list-rules4 fields changed- added
Input schema / properties / limitAdded value: +{ + "default": 50, + "description": "How many rules to return, at most.", + "maximum": 50, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Where the page starts: 0, or the nextOffset of the page before.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "The offset of the next page, when there is one.", + "type": "number" +} - added
Output schema / properties / total / descriptionAdded value: +"How many rules match, on every page."
6 tool updates
- First observed
get-contract - First observed
get-page - First observed
get-reference-implementation - First observed
list-components - First observed
list-rules - First observed
search-docs
Related MCP Connectors
A design harness for AI coding agents: design systems, design principles, icons and UI review.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Mlola UI components, tokens and design rules for coding agents, with a markup checker
Orvain UI design system for React and Vue: real component props, variants and tokens for AI tools
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI coding assistants to generate bespoke design systems by synthesizing OKLCH color palettes, chamfer highlights and spring physics, teaching layout composition grammar, and returning micro-interaction primitives and component blueprints. Also audits JSX/TSX/HTML through a senior design director's lens to score and critique UI quality.2 npm1MIT
- AlicenseBqualityDmaintenanceProvides AI assistants with tools to grade, generate, and validate UI components against the components.build specification. Supports searching documentation, checking compliance, and generating framework-agnostic accessible components.118 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEquips coding agents with curated design rules, art directions, UI audits, component discovery, and reference guides so they can produce less generic, more polished interfaces in Claude Code, Codex, Cursor, and other MCP clients.MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.