Open Components

com.uxfront由 uxfront.com 發布v1.0.0更新於 Oct 24, 2026

Guidelines for UI components with a perfect UX, DX and AX, whether humans or AI agents write them.

已驗證Streamable HTTP可網頁執行知識與記憶開發者工具

概覽

AI 產生的概覽

一個遠端 MCP 伺服器,為助理提供 Open Components UI 標準:元件契約、檢查清單規則、文件與參考實作。

可以做什麼
列出已涵蓋的元件、基礎規範與路線圖項目,並依主題或 ID 搜尋整個標準中的頁面與規則。以 YAML 讀取元件或基礎規範的契約:API、DOM 契約、權杖以及每條帶 ID、層級與範圍的檢查清單規則。以 markdown 讀取文件頁面,可整頁或指定章節,並依框架篩選範例。依元件、ID、範圍、層級、等級或檢查方式篩選檢查清單規則。取得已發布元件的參考實作及其測試、輔助函式與主題權杖。
適用情境
在建立或審查應遵循 Open Components 標準的 UI 元件時使用,或需要某條規則的理由、可引用的規則 ID,以及 Button 等元件的可用參考實作時使用。
執行需求
透過 streamable HTTP 連線至 mcp.opencomponents.dev 遠端端點;README 稱其免費且無需登入。未宣告任何套件、環境變數或請求標頭。
安裝前請注意
僅對已發布的文件與程式碼進行唯讀存取;未宣告憑證、付費或寫入操作。回傳內容為第三方指引,套用到程式碼庫前請自行審閱。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Open Components,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

交給代理程式安裝

把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式,或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南,先向你展示發布者、端點和登入方式,經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。

閱讀 https://sourceweft.com/mcp/com.uxfront%2Fopen-components/install.md,並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前,先告訴我它的發布者、端點和登入方式,等我確認。不要把 API 金鑰寫進命令或我會提交的檔案;問我金鑰應從哪裡取得。

檢視代理程式所依據的安裝指南

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "open-components": {
      "type": "http",
      "url": "https://mcp.opencomponents.dev/mcp"
    }
  }
}

README

[Open Components]

Open Components

Open Components is the standard for perfect UI components: guidelines for building UI components with a perfect user experience, developer experience and agentic experience, whether humans or AI agents write them.

Open Components is part of UXFront, written and maintained by @alexgrozav.


[Open Components - The standard for perfect UI components]


Homepage · Documentation · Changelog · llms.txt · Issue Tracker


[Website] [llms.txt] [Last commit]



Table of contents

The standard

The standard has three layers, one for each audience a component serves. A component meets the standard when it meets all three.

  • User experience (UX): components behave the way people expect them to, with any input, on any device and for every ability. Accessible, predictable, every state, adaptive.
  • Developer experience (DX): one clear API, learned once and used everywhere. Knowing one component means knowing them all. Consistent, type-safe, composable, controllable.
  • Agentic experience (AX): components that AI agents can read, reason about and build with, so their output meets the same bar as yours. Semantic, described, deterministic, verifiable.

Learn the guidelines once, then hold every component to the same high standards, whether you or your agents write it.

Reading the standard

Start with the Introduction, which walks through the three layers and what each one asks of a component. The guidelines live as markdown in content/docs/, so you can also read them right here on GitHub.

For agents

If your agent supports MCP, connect it to our MCP server at https://mcp.opencomponents.dev/mcp, free and with no sign-in. It gives agents the contracts, every rule and the docs a section at a time, as tools. The MCP Server page shows how to connect Claude, Codex, Cursor, VS Code, Gemini CLI, Grok, Hermes Agent and other clients.

Or install our agent plugin, in plugins/open-components, which connects the same server along with skills that build and review components the way the standard asks. It's an Agent Plugin, so it works in VS Code, GitHub Copilot, Cursor, Codex, Claude Code and other clients that support the format. The Agent Plugin page shows how to install it.

Every page of the documentation is also published as markdown, so agents can read the standard and check their work against it:

  • https://opencomponents.dev/raw/<path>.md holds one page, as in /raw/docs/getting-started/introduction.md for the introduction.
  • https://opencomponents.dev/raw/<path>.yaml holds a page's contract, with every rule from its checklist, as in /raw/docs/components/button.yaml. It's every requirement in a fraction of the page's length.
  • /schemas/contract.json is the JSON Schema every contract follows, so you can validate them, and contracts of your own. Each contract names it on its first line, so editors that use the YAML language server check it as you type.
  • /llms.txt lists every page and every contract.
  • /llms-full.txt holds them all in one file. Point your agent at it to give it the whole standard in one request.

Bugs and feature requests

Found a bug on the site, a gap in the guidelines or an idea for a new one? Please first search for existing and closed issues. If your problem or idea is not addressed yet, please open a new issue.

Contributing

Please read through our contributing guide. There you can find how to run the site locally, edit the guidelines and deploy. Everyone taking part in the project agrees to follow our Code of Conduct.

Thanks goes to these wonderful people!

Creator

Alex Grozav

If you use Open Components in your daily work and feel that it has made your life easier, please consider sponsoring me on GitHub Sponsors. 💖

Copyright and license

Copyright © 2026 UXFront. The site code is released under the MIT License. The guidelines in content/ and the agent plugin in plugins/open-components/ are released under the Creative Commons Attribution 4.0 License: you can share and adapt them, commercially too, as long as you credit Open Components.

來源:README.md,提交 95746d1

工具

6

get-contract

Get Contract

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/<path>.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.

輸入參數component必填

get-page

Get Page

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.

輸入參數path必填sectionsframework

get-reference-implementation

Get Reference Implementation

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.

輸入參數filescomponent必填

list-components

List Components

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.

輸入參數status

list-rules

List Rules

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.

輸入參數idschecklayerlevellimitscopeoffsetautomatedcomponent

search-docs

Search Docs

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.

輸入參數typelimitquery必填component

版本歷史

1
  1. v1.0.0最新Oct 10, 2026

評分

已滿足適用檢查項的 100%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通必需25 分
  • 已宣告認證方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分