Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Questionnaire Component Governance MCP Demo get the governance rule for the 'option-select' component"
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.
一个面向问卷编辑器场景的 MCP 小 demo，用来演示如何把组件治理能力结构化为 Resources、Tools 和 Prompts，并让 AI Agent 在组件使用、规则查询和开发约束场景里复用这套能力。
这个 demo 主要解决两个问题：
把组件规范从零散文档沉淀为机器可读的结构化规则。
让 AI Agent 在生成或修改问卷组件时，先读取规范、再执行校验，最后给出建议或约束结果。
Related MCP server: web-ui-component-spec-mcp
governance://component-guidelines
暴露组件治理文档，提供职责边界、状态管理约束、AI 使用约束等通用规则。
governance://component-rules
暴露完整组件规则 JSON，提供组件名称、必传属性、允许属性、禁止模式、使用示例等结构化数据。
list_component_rules
列出当前已注册的问卷组件规范。
get_component_rule
查询某个组件的详细规范。
validate_component_usage
校验组件 props 是否符合治理规则。
build_component_prompt
根据任务和组件规则生成给 AI Agent 使用的开发提示。
create-question-component
给 Agent 一个标准化的新增题型组件工作流，要求其遵守现有治理规范完成组件设计与接入。
.
|-- rules/
| |-- components.json
| `-- guideLines.md
|-- src/
| |-- index.ts
| |-- loadRules.ts
| |-- schemas.ts
| `-- validateRules.ts
`-- dist/npm install
npm run ci
npm run dev这个 demo 更偏“治理能力建模”而不是完整业务系统，重点在于：
如何把组件规范做成可读的 MCP Resources
如何把组件校验做成可执行的 MCP Tools
如何把 AI 开发流程固化为可复用的 Prompt 模板
根据组件规范生成一段给 AI Agent 使用的开发提示词
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | 开发任务，例如 新增一个单选题组件 | |
| componentName | No | 可选，指定组件名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only states what the tool does without disclosing any behavioral traits (e.g., side effects, output format, or dependencies). More detail is needed for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two simple parameters, the description lacks details about the generated prompt format, intended usage, or any constraints. A more complete description would mention the output structure or expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal new meaning beyond 'based on component specification,' which is already implied by the task parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a development prompt for AI Agent based on component specification. It uses a specific verb ('生成') and resource ('开发提示词'), and the purpose is distinct from sibling tools which deal with component rules and validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, the purpose is sufficiently differentiated from siblings by domain (prompt generation vs. rules/validation), so an agent may infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据组件名称查询组件使用规范、必传属性、禁止用法和示例
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | 组件名称，例如 QuestionInput、QuestionRadio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates a read-like operation (query) but does not disclose authentication needs, rate limits, or side effects. For a simple lookup, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality efficiently. It is front-loaded with the verb '查询' (query) and the resource '组件使用规范'. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema, no annotations), the description adequately covers what the tool does and what it returns. It is complete for a straightforward lookup operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter componentName described with examples. The description adds no new parameter meaning beyond what the schema provides, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: query component usage specifications by component name, listing what is returned (usage specs, required props, prohibited usages, examples). It differentiates from sibling tools like build_component_prompt or list_component_rules by focusing on specific rule retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing component-specific rules but does not explicitly state when to use this tool versus alternatives or when not to use it. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出问卷系统中所有已注册的组件规范
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description alone must disclose behavior. It states it lists registered components but does not mention pagination, ordering, or response structure. Minimal transparency for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. Adequately concise for a zero-parameter tool, though it could add a bit more context without harm.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations, so description is the sole source. It does not specify what fields are returned (e.g., name, ID, constraints). For a list tool, this is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter information. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all registered component specifications in the questionnaire system. It distinguishes from sibling tools like get_component_rule (single rule) and validate_component_usage (validation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (when you need to see all components), but there is no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
校验某个问卷组件的 props 是否符合组件规范
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | 组件名称，例如 QuestionInput | |
| props | Yes | 组件实际传入的 props 对象 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'validate', but does not reveal whether it is read-only, what happens on failure, or if it requires authentication. This leaves agents guessing about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but may be too terse. It lacks structure and front-loaded critical info like output behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and behavioral details, the description is incomplete. It does not explain what the tool returns (success/error) or how it relates to sibling tools like build_component_prompt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds no extra meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates component props against a specification. However, it does not distinguish it from sibling tools like get_component_rule, but given the different verbs (validate vs get), it is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites or contexts where validation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0build_component_promptget_component_rulelist_component_rulesvalidate_component_usageScored across 4 tools
Each tool has a clearly distinct purpose: generating prompts, retrieving individual rules, listing all rules, and validating component usage. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., build_component_prompt, get_component_rule), making them predictable and easy to understand.
With only 4 tools, the server is tightly scoped to core component governance tasks. Each tool earns its place without redundancy or missing essentials.
The tools cover listing, retrieval, validation, and prompt generation—the main governance workflows. Missing create/update/delete for rules is a minor gap, but acceptable for a demo server.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Serves your design system and coding standards to coding agents, so they stop guessing.
AI agent governance with resolved business context, current decisions, provenance, and supersession.
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
