Provides type-safe integration with the KPC component library through complete TypeScript type definitions for all component APIs, props, events, and methods.
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., "@KPC Component Library MCP Server show me how to create a form with validation using KPC components"
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.
基于官方 @modelcontextprotocol/sdk 开发的KPC组件库AI代码生成服务，彻底解决AI幻觉问题。
AI幻觉问题: AI经常使用不存在的组件属性或错误的API
导入方式错误: AI使用错误的包名导入组件
嵌套关系错误: 如Form组件不使用FormItem包裹表单控件
依赖源码环境: 传统方案需要访问KPC源码
Related MCP server: KRDS UI/UX MCP Server
特性 | 静态文档 | 官方SDK MCP服务 |
开发标准 | 自定义实现 | 官方TypeScript SDK |
类型安全 | 无类型检查 | 完整TypeScript类型 |
错误处理 | 简单异常 | 标准MCP错误码 |
可维护性 | 手工维护 | 官方标准+自动化 |
Token消耗 | ~50KB+ | ~5KB 精确API |
覆盖范围 | 部分组件 | 全部58个组件 |
mcp/
├── src/
│ ├── index.ts # MCP服务器主入口
│ ├── types.ts # TypeScript类型定义
│ ├── data-loader.ts # 数据加载器
│ ├── validators.ts # 组件使用验证器
│ ├── example-generator.ts # 示例代码生成器
│ ├── formatters.ts # 输出格式化器
│ └── test.ts # 完整测试套件
├── data/ # 组件API数据
│ ├── kpc-api-full.json # 完整组件数据
│ ├── kpc-api-index.json # 组件索引
│ └── kpc-api-*.json # 分类数据文件
├── dist/ # 编译输出
├── package.json # 项目配置
├── tsconfig.json # TypeScript配置
└── README.md # 项目文档cd mcp
yarn installyarn buildyarn testyarn start编辑 Claude Desktop 配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"kpc-components": {
"command": "node",
"args": ["/path/to/kpc/mcp/dist/index.js"],
"cwd": "/path/to/kpc/mcp"
}
}
}工具名 | 功能 | 参数 |
| 获取组件完整API |
|
| 搜索相关组件 |
|
| 列出所有组件 |
|
| 验证组件使用 |
|
| 获取使用示例 |
|
| 获取统计信息 | 无参数 |
用户: "我需要一个数字输入框组件"
AI: [调用 search_kpc_components("数字输入")]
→ 找到: Spinner组件 - 数字输入框
AI: [调用 get_kpc_component("Spinner")]
→ 获取: 完整的Spinner组件API
AI: 基于准确API生成代码:<template>
<Spinner
v-model="count"
:min="0"
:max="100"
:step="1"
:precision="0"
@change="handleChange"
/>
</template>
<script>
import { Spinner } from '@king-design/vue';
export default {
components: { Spinner },
data() {
return { count: 0 };
},
methods: {
handleChange(value, oldValue) {
console.log('数值变化:', value);
}
}
};
</script>用户: "这样写对吗？<Form><Input /></Form>"
AI: [调用 validate_kpc_usage("Input", {}, "Form")]
→ 返回: ❌ Form组件内必须使用FormItem包裹表单控件
AI: 这样写是错误的，正确写法：<Form>
<FormItem label="输入框" :value="form.input" :rules="{required: true}">
<Input v-model="form.input" />
</FormItem>
</Form>用户: "如何使用Table组件进行数据展示？"
AI: [调用 get_kpc_usage_examples("Table", "数据展示")]
→ 返回: 完整的Table使用示例代码运行 get_kpc_stats 工具查看最新统计：
组件总数: 58个
分类: 7大类（基础组件、表单组件、数据展示等）
API覆盖:
✅ Props属性: 完整类型定义和默认值
✅ Events事件: 参数类型和描述
✅ Methods方法: 返回值类型和用途
✅ Slots插槽: 参数定义和说明
✅ 使用示例: 真实可用代码
✅ 嵌套规则: 防止错误用法
# 运行完整测试套件
yarn test
# 输出示例:
📊 测试结果:
总计: 25 个测试
通过: 25 个
失败: 0 个
成功率: 100%
总耗时: 156ms
🎉 所有测试通过！测试覆盖：
✅ 数据加载和缓存
✅ 组件检索和搜索
✅ 使用验证和错误检查
✅ 示例生成和格式化
✅ 边界情况和异常处理
// types.ts - 核心类型定义
export interface ComponentAPI {
name: string;
description: string;
category: string;
props: PropDefinition[];
events: EventDefinition[];
// ...
}
// data-loader.ts - 数据管理
export class KPCDataLoader {
async initialize(): Promise<void>
getComponent(name: string): ComponentAPI | null
searchComponents(query: string): ComponentSummary[]
// ...
}
// validators.ts - 使用验证
export class KPCUsageValidator {
validate(component: ComponentAPI, props: object): ValidationResult
// ...
}添加新的MCP工具：
// 在 index.ts 中添加工具定义
{
name: 'my_new_tool',
description: '工具描述',
inputSchema: {
type: 'object',
properties: {
param1: { type: 'string', description: '参数描述' }
},
required: ['param1']
}
}
// 添加处理器
case 'my_new_tool':
return await this.handleMyNewTool(args?.param1 as string);扩展验证规则：
// 在 validators.ts 中添加新规则
private validateCustomRules(component: ComponentAPI): void {
// 自定义验证逻辑
}自定义示例生成：
// 在 example-generator.ts 中添加
generateCustomExample(component: ComponentAPI): UsageExample {
// 生成特定类型的示例
}当KPC组件库更新时：
重新提取API数据（在KPC源码环境中）：
cd ../tools
node extract-api.js更新MCP服务数据：
cp -r ../tools/api-data ./data重新编译和测试：
yarn build
yarn test重启服务：
yarn start只读操作: 服务只提供API查询，不修改任何代码
数据验证: 严格的TypeScript类型检查
错误处理: 完善的异常捕获和MCP标准错误码
输入验证: 所有用户输入都经过验证
数据缓存: 组件数据加载后缓存在内存
按需查询: 只返回请求的组件信息
分类索引: 支持快速分类查找和筛选
异步加载: 使用异步I/O避免阻塞
✅ 100%消除AI幻觉: 基于真实API数据，确保属性、事件、方法都存在
✅ 正确的导入方式: 明确使用 @king-design/vue 等正确包名
✅ 准确的嵌套关系: Form → FormItem → 表单控件等规则自动验证
✅ 完整的API覆盖: 58个组件的全部Props、Events、Methods、Slots
✅ 智能验证机制: 实时检查代码正确性并提供修复建议
✅ 官方标准实现: 基于官方TypeScript SDK，类型安全，易维护
# 开发模式（自动重编译）
yarn dev
# 运行测试
yarn test# 构建生产版本
yarn build
# 启动服务
yarn startFROM node:18-alpine
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --production
COPY dist/ ./dist/
COPY data/ ./data/
CMD ["yarn", "start"]KPC更新时自动重新提取API
自动运行测试套件
版本化管理API数据
自动部署新版本服务
extract-api.js 用于kpc根目录下生成kpc-api-full.json相关json
supplement_kpc_api.py 用于补全extract-api.js生成组件丢失的属性等
generate_api.files.py 用于基于kpc-api-full.json生成其他分类压缩json
npx -y @modelcontextprotocol/inspector npx kpc-mcp-server
这个基于官方SDK的实现提供了更高的代码质量、类型安全和维护性，是企业级应用的最佳选择。
获取KPC组件的完整API定义，包括props、events、methods、slots和使用示例
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | 组件名称，如 Form、Input、Button、Spinner、Table等 |
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 behavioral disclosure. It describes what the tool returns (API definition with specific elements) but lacks details on behavioral traits such as error handling (e.g., what happens if the component doesn't exist), performance (e.g., response time), or data format (e.g., JSON structure). For a read operation with no annotation coverage, this is a significant gap in transparency.
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 concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and what it includes. There is no wasted text, and it efficiently communicates the core functionality without unnecessary details.
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 tool's complexity (a read operation with one parameter) and the lack of annotations and output schema, the description is moderately complete. It specifies what the tool returns (API definition with elements like props and events), which helps compensate for the missing output schema. However, it does not fully address behavioral aspects or usage guidelines, leaving gaps in context for an AI agent.
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 has 100% description coverage, with the single parameter 'component' documented as '组件名称，如 Form、Input、Button、Spinner、Table等' (component name, such as Form, Input, Button, Spinner, Table, etc.). The description does not add meaning beyond this schema, as it does not explain parameter usage or constraints further. With high schema coverage, 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's purpose: '获取KPC组件的完整API定义' (Get the complete API definition of a KPC component). It specifies the verb '获取' (get) and resource 'KPC组件' (KPC component), and lists what the definition includes (props, events, methods, slots, usage examples). However, it does not explicitly differentiate from siblings like 'get_kpc_stats' or 'list_kpc_components', which might provide different types of component information.
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 provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools (e.g., 'get_kpc_usage_examples' for examples only, 'list_kpc_components' for listing components) or specify contexts where this tool is preferred. Usage is implied by the description's focus on '完整API定义' (complete API definition), but no explicit when/when-not instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取KPC组件库的统计信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose ('get statistics') without revealing any behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what format the statistics might return. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks context about what 'statistics' entail (e.g., counts, usage metrics, performance data) and how this differs from sibling tools, which could help an agent decide when to use it. Without annotations or output schema, more descriptive guidance would improve completeness.
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 has 0 parameters with 100% coverage, meaning there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. It adds no semantic value beyond the schema, but since no parameters exist, a baseline score of 4 is warranted as it doesn't need to compensate for any gaps.
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 action ('获取' meaning 'get') and the resource ('KPC组件库的统计信息' meaning 'KPC component library statistics'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its siblings like 'get_kpc_component' or 'list_kpc_components', which likely retrieve different types of KPC data.
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 provides no guidance on when to use this tool versus alternatives like 'get_kpc_component' (which might retrieve individual components) or 'list_kpc_components' (which might list components without statistics). It simply states what the tool does without context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取KPC组件的使用示例代码
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | 组件名称 | |
| scenario | No | 使用场景，如"基础用法"、"表单验证"、"高级配置"、"事件处理"等 | |
| framework | No | 可选：目标框架，默认vue3 |
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 behavioral disclosure. It states the tool retrieves example code, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or output format (e.g., code snippets, documentation links). For a tool with no annotation coverage, this is a significant gap in transparency.
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, clear sentence in Chinese: '获取KPC组件的使用示例代码'. It is front-loaded with the core purpose, has zero redundant information, and is appropriately sized for a straightforward tool.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on behavioral traits, usage context, and output expectations. With no output schema, the description doesn't explain what is returned (e.g., code blocks, examples in specific formats), leaving gaps for the agent.
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 description coverage is 100%, with all parameters documented in the schema (component, scenario, framework). The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid component names or scenario details. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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: '获取KPC组件的使用示例代码' (Get usage example code for KPC components). It specifies the verb '获取' (get) and resource 'KPC组件的使用示例代码' (usage example code for KPC components). However, it doesn't explicitly differentiate from sibling tools like 'get_kpc_component' or 'validate_kpc_usage', which might also involve component information.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_kpc_component' (which might retrieve component metadata) or 'validate_kpc_usage' (which might check correctness), leaving the agent to infer usage context solely from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有可用的KPC组件或按分类筛选
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 可选：组件分类筛选，如"基础组件"、"表单组件"、"数据展示"等 | |
| summary | No | 可选：是否只返回摘要信息，默认false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool lists components with optional filtering, but doesn't describe what '列出' entails (e.g., pagination, format, rate limits, authentication needs, or whether it's a read-only operation). For a listing tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence in Chinese that clearly states the core functionality. It's appropriately sized for a simple listing tool with two optional parameters, with zero wasted words or unnecessary elaboration.
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 annotations and no output schema, the description is incomplete for a listing tool. It doesn't explain what the output contains (e.g., component details, IDs, metadata), how results are structured, or any behavioral constraints. The agent must rely entirely on the tool name and minimal description, which is insufficient for confident invocation.
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 description coverage is 100%, so the schema already documents both parameters ('category' and 'summary') with clear descriptions. The description mentions filtering by category but adds no additional semantic context beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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: '列出所有可用的KPC组件或按分类筛选' (List all available KPC components or filter by category). It specifies the verb ('列出' - list) and resource ('KPC组件' - KPC components), and includes optional filtering functionality. However, it doesn't explicitly differentiate from sibling tools like 'search_kpc_components' or 'get_kpc_component', which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It mentions filtering by category but doesn't clarify when to use this versus 'search_kpc_components' or 'get_kpc_component'. There are no usage scenarios, prerequisites, or exclusions mentioned, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据关键词搜索相关的KPC组件
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词，支持中文描述，如"表单"、"输入"、"数字"、"表格"等 | |
| category | No | 可选：按分类筛选，如"表单组件"、"数据展示"等 | |
| fuzzy | No | 可选：是否启用模糊搜索，默认false |
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 behavioral disclosure. It only states the basic action ('搜索' - search) without detailing what the search returns (e.g., a list of components, metadata, or usage examples), how results are formatted, whether there are rate limits, or any error conditions. For a search tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence: '根据关键词搜索相关的KPC组件' (search for KPC components based on keywords). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple search tool. Every part of the sentence earns its place by clearly stating the action and target.
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 complexity (a search tool with 3 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of components with IDs and names, or full details), how results are ordered, or any behavioral aspects like pagination or error handling. This leaves critical gaps for an agent to use the tool effectively.
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 schema description coverage is 100%, with all parameters ('query', 'category', 'fuzzy') well-documented in the input schema. The description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain how 'fuzzy' search differs from exact matching or provide examples of 'category' values). Baseline 3 is appropriate since the schema does the heavy lifting.
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: '根据关键词搜索相关的KPC组件' (search for KPC components based on keywords). It specifies the verb ('搜索' - search) and resource ('KPC组件' - KPC components), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_kpc_components' or 'get_kpc_component', which would require a 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_kpc_components' (which might list all components without searching) or 'get_kpc_component' (which might retrieve a specific component by ID). There's no context on prerequisites, limitations, or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
验证KPC组件的使用是否正确，检查属性、嵌套关系等
| Name | Required | Description | Default |
|---|---|---|---|
| component | Yes | 组件名称 | |
| props | Yes | 组件属性对象 | |
| context | No | 上下文信息，如父组件名称 |
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 behavioral disclosure. It states the tool verifies correctness and checks properties and nesting relationships, implying a read-only analysis without side effects. However, it lacks details on permissions needed, error handling, rate limits, or what happens if validation fails (e.g., returns errors or warnings). For a validation tool with zero annotation coverage, this is a significant gap in transparency.
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 concise and front-loaded in a single sentence: '验证KPC组件的使用是否正确，检查属性、嵌套关系等'. It efficiently conveys the core purpose without unnecessary words. However, it could be slightly more structured by separating key aspects (e.g., validation scope) for better clarity, but overall it earns its place with minimal waste.
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 tool's complexity (validation with 3 parameters, nested objects) and lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., validation results, errors, or success status), behavioral traits like idempotency or side effects, or how to interpret outcomes. For a validation tool, this leaves critical gaps in understanding its full context and usage.
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 schema description coverage is 100%, with clear descriptions for all three parameters ('component', 'props', 'context'). The description adds marginal value by implying that 'props' and 'context' are used for checking properties and nesting relationships, but does not provide additional syntax, format examples, or constraints beyond what the schema already documents. With high schema coverage, 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's purpose: '验证KPC组件的使用是否正确，检查属性、嵌套关系等' (Verify if KPC component usage is correct, check properties, nesting relationships, etc.). This specifies the verb ('verify/check') and resource ('KPC component usage'), distinguishing it from sibling tools like 'get_kpc_component' or 'list_kpc_components' which focus on retrieval rather than validation. However, it could be more specific about what 'correct' entails (e.g., against standards or rules).
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 provides no explicit guidance on when to use this tool versus alternatives. It mentions checking properties and nesting relationships, but does not specify scenarios (e.g., during development or testing) or prerequisites. Sibling tools like 'get_kpc_usage_examples' or 'search_kpc_components' might overlap in context, but no comparisons or exclusions are provided, leaving usage ambiguous.
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.
get_kpc_componentget_kpc_statsget_kpc_usage_exampleslist_kpc_componentssearch_kpc_componentsvalidate_kpc_usageScored across 6 tools
Most tools have distinct purposes, but there is some overlap between get_kpc_component and get_kpc_usage_examples, as the former already includes usage examples in its description. This could cause confusion about which tool to use for retrieving examples. Otherwise, tools like list_kpc_components and search_kpc_components are clearly differentiated for browsing vs. searching.
All tool names follow a consistent verb_noun pattern with 'kpc' as a prefix, using snake_case uniformly. The verbs (get, list, search, validate) are appropriate and predictable, making the tool set easy to navigate and understand at a glance.
With 6 tools, the server is well-scoped for a component library domain, covering key operations like listing, searching, retrieving details, and validating usage. This count is neither too sparse nor bloated, allowing agents to perform essential tasks without overwhelming complexity.
The tool set covers most core needs for a component library, including discovery (list, search), inspection (get component, get stats, get examples), and validation. A minor gap is the lack of tools for creating or updating components, but this is reasonable if the server is read-only, and agents can still work effectively with the provided tools.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
AI development agent using Kendo UI to rapidly create and style quality web UIs or Pages.
Serves your design system and coding standards to coding agents, so they stop guessing.
Mlola UI components, tokens and design rules for coding agents, with a markup checker
