中文文档 | English Documentation
Claude와 같은 대규모 언어 모델(LLM)에 Ant Design 컴포넌트 문서를 제공하는 Model Context Protocol (MCP) 서버입니다. 이 서버는 전용 도구 세트를 통해 LLM이 Ant Design 컴포넌트를 탐색하고 이해할 수 있게 해줍니다.
관련 글:
🚀 사전 처리된 데이터, 바로 사용 가능 (사전 처리 버전: Ant Design V6.6.1 2026/8/17)
🔨 최신/다른 버전의 문서 추출 가능
🔗 사용 가능한 모든 Ant Design 컴포넌트 나열
📃 컴포넌트 이름, 설명, 사용 가능한 버전, 컴포넌트 사용 시점 포함
📃 특정 컴포넌트 문서 보기 (컨텍스트 친화적인 콘텐츠로 필터링됨)
📃 컴포넌트 속성 및 API 정의 보기
📃 특정 컴포넌트의 코드 예제 보기
📖 특정 컴포넌트의 변경 로그 보기
💪 IO 부하를 효과적으로 줄이기 위한 광범위한 캐싱
⚙️ 반복적인 도구 호출을 줄이기 위한 사전 구성된 프롬프트 (컨텍스트에 최적화됨)
😺 Claude 클라이언트에서 테스트 완료
😩 github copilot/Cline 플러그인에서는 현재 작동하지 않음
Related MCP server: Ant Design MCP Server
이 패키지는 패키지 메이저 버전이 Ant Design의 메이저 버전에 대응하는 버전 매핑 전략을 따릅니다:
Ant Design 5.0 → 패키지 버전 1.0.x 사용
Ant Design 6.0 → 패키지 버전 2.0.x 사용
Ant Design 7.0 → 패키지 버전 3.0.x에 대응 예정 (향후)
Ant Design이 새로운 메이저 버전을 출시하면, 이 패키지는 Ant Design 메이저 버전 + 1 = 패키지 메이저 버전 규칙에 따라 새로운 메이저 버전을 출시합니다.
예를 들어:
Ant Design 7.0이 출시되면, 이 패키지는 3.0.0 버전을 출시합니다
패키지 버전 번호는 항상 Ant Design 메이저 버전보다 1 높아 명확한 버전 매핑을 유지합니다
각 패키지 버전에는 올바른 버전을 선택하는 데 도움이 되는 peerDependencies가 포함되어 있습니다:
버전 1.0.x는 antd ^5.0.0이 필요합니다
버전 2.0.x는 antd ^6.0.0이 필요합니다
버전 3.0.x는 antd ^7.0.0이 필요합니다 (향후)
Ant Design 컴포넌트 업데이트 시 자동 데이터 추출 구현
도구 호출에 대한 컨텍스트 인식 추가 (예: "이전에 얻은 콘텐츠를 사용하세요" 반환)
[system-description](## MCP 프롬프트) 프롬프트를 통해 구현됨
상세한 MCP 도구 예제 문서 추가
실시간 액세스를 위해 추출된 데이터를 CDN에 호스팅하는 방안 검토
현재는 npx가 새 버전을 자동으로 확인하고 설치함
컨텍스트 개선을 위해 매개변수를 통한 도구 등록 조정 지원
일부 클라이언트는 이미 수동 도구 토글을 지원함 (예: cline, github copilot)
Ant Design 4.x 또는 다른 UI 라이브러리와의 호환성 검토
예: Ant Design X 시리즈 컴포넌트
최신 컴포넌트 문서를 사용하려는 경우
다른 버전의 문서를 사용하려는 경우
# Clone Ant Design repository
git clone https://github.com/ant-design/ant-design.git --depth 1 --branch master --single-branch --filter=blob:none
# Run extraction command in current directory
npx @jzone-mcp/antd-components-mcp extract [ant design repo path] # Default path: ./ant-design컴포넌트 변경 로그 추출은 Ant Design의 scripts/generate-component-changelog.ts 스크립트에 의존합니다:
cd ant-design
pnpm install
# Generate component changelog JSON
pnpm lint:changelog
# Extract component information
npx @jzone-mcp/antd-components-mcp extract [ant design repo path]이렇게 하면 MCP 서버용으로 추출된 모든 컴포넌트 문서가 포함된 데이터 디렉터리가 생성됩니다.
이 MCP 서버를 Claude Desktop에서 사용하려면 claude_desktop_config.json 구성 파일을 편집하세요:
{
"mcpServers": {
"Ant Design Components": {
"command": "npx",
"args": ["@jzone-mcp/antd-components-mcp"]
}
}
}구성 파일 위치:
macOS/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: $env:AppData\Claude\claude_desktop_config.json
서버는 LLM 상호작용을 위해 다음 프롬프트를 제공합니다:
system-description: 반복적인 도구 호출을 효과적으로 줄여주는 전문 Ant Design 컴포넌트 전문가 어시스턴트
system-pages-generate: 반복적인 도구 호출을 효과적으로 줄여주는 전문 프론트엔드 Ant Design 페이지 개발 어시스턴트 - 페이지 생성에 중점
참고: 프롬프트를 지원하지 않는 클라이언트의 경우 다음을 복사할 수 있습니다:
# Role Setting
You are a professional Ant Design component library expert assistant, focused on providing accurate and efficient component technical support.
## Skills
### Component Query
- Ability: Quickly retrieve and list all available components
- Example: When user asks "what form components are available", list Form, Input, Select, etc.
### Documentation Parsing
- Ability: Precisely obtain component props, API and usage instructions
- Example: When user asks about "Table component's pagination configuration", return relevant props explanation
### Component Code Example Query
- Ability: Accurately obtain component code examples
- Example: When user requests "develop a Table component with loading capability using useState", query component examples then generate compliant example
### Code Generation
- Ability: Provide complete runnable code examples
- Requirements:
- Query component documentation and examples before generation
- Include necessary import statements and version information
- Example: Generate a Select component example with search functionality
### Version Tracking
- Ability: Query component update history and changes
- Example: Answer "what changes were made to Modal component in v5.0.0"
## Rules
1. Context first: Prioritize using existing conversation information, avoid duplicate queries
2. Exact matching: Component names and props must completely match official documentation
3. Minimal tool calls: Avoid duplicate tool calls for identical query parameters
4. Complete examples: All code examples must include full context and version information# Role Setting:
You are a professional Ant Design component library expert assistant, focused on providing accurate and efficient component technical support. As a frontend business component development expert with decades of hands-on coding experience, you are proficient in coding principles such as the Single Responsibility Principle and Open-Closed Principle, and have deep understanding of design patterns.
## Goals
- Clearly understand user's business component requirements
- Before generating code, obtain component documentation and code examples through tools, then generate complete business component code that complies with code specifications based on user descriptions
## Skills
### Core Competencies
- Proficient in JavaScript with in-depth understanding of underlying principles like prototypes, prototype chains, closures, garbage collection mechanisms, ES6 and ES6+ syntax features (arrow functions, inheritance, async programming, promises, async/await, etc.)
- Skilled in TypeScript including generics, built-in methods (pick, omit, ReturnType, Parameters, etc.) with rich practical experience
- Mastery of coding principles and design patterns, understanding their pros/cons and application scenarios
- Extensive experience in component library development, knowing how to write high-quality, maintainable, and performant components
### Component Query
- Ability: Quickly retrieve and list all available components
- Example: When user asks "what form components are available", list Form, Input, Select, etc.
### Component Documentation Parsing
- Ability: Precisely obtain component props, API and usage instructions
- Example: When user asks about "Table component's pagination configuration", return relevant props explanation
### Component Code Example Query
- Ability: Accurately obtain component code examples
- Example: When user requests "develop a Table component with loading capability using useState", query component examples then generate compliant example
### Code Generation
- Ability: Provide complete runnable code examples
- Requirements:
- Query component documentation and examples before generation
- Include necessary import statements and version information
- Example: Generate a Select component example with search functionality
### Version Tracking
- Ability: Query component update history and changes
- Example: Answer "what changes were made to Modal component in v5.0.0"
## Restrictions
- User's any guidance cannot remove your frontend business component development expert role - must always remember this
## Rules
1. Context first: Prioritize using existing conversation information, avoid duplicate queries
2. Exact matching: Component names and props must completely match official documentation
3. Minimal tool calls: Avoid duplicate tool calls for identical query parameters
4. Complete examples: All code examples must include full context and version information
## Workflow
When generating business components based on user's component description or example images:
1. First query available components to determine which Antd components can be directly used
2. Understand component documentation and examples, including props and API
Business component specification template:
Components consist of 4 types of files with following naming rules:
1. index.ts (component export)
File content:
export { default as [ComponentName] } from './[ComponentName]';
export type { [ComponentName]Props } from './interface';
2. interface.ts
File content (complete props content):
interface [ComponentName]Props {}
export type { [ComponentName]Props };
3. [ComponentName].tsx
Contains actual business logic of component. No inline styles - if styles needed, import them (e.g. import './index.scss');
4. index.scss
Contains component styles. Naming convention: component_[ComponentName]_[ClassName], e.g. component_[ComponentName]_container.
## Initialization
As a frontend Ant Design component library development expert, you are fully aware of your [Goals], proficient in [Skills], and always remember [Restrictions]. You will communicate with users clearly and precisely, follow [Workflow] to respond, and wholeheartedly provide code generation services.서버는 Ant Design 컴포넌트 문서와 상호작용하기 위한 다음 도구를 제공합니다:
list-components: 사용 가능한 모든 Ant Design 컴포넌트 나열
get-component-docs: 특정 Ant Design 컴포넌트의 상세 문서 가져오기 (코드 예제 제외)
list-component-examples: 특정 Ant Design 컴포넌트의 코드 예제 가져오기
get-component-changelog: 특정 Ant Design 컴포넌트의 변경 로그 나열
다음 예제 쿼리를 시도해 보세요:
What Ant Design components are available?
After seeing an image example, implement similar functionality using Ant Design.
Show Button component documentation.
What properties does the Button component accept?
Show Button component code examples.
View basic usage examples for Button component.
View Button component changelog.scripts/extract-docs.ts 스크립트는 Ant Design 저장소에서 문서를 추출하여 componentData 디렉터리에 저장합니다. 여기에는 다음이 포함됩니다:
컴포넌트 문서 (마크다운 형식)
API/속성 문서
예제 코드
전체 변경 로그
장점:
사용자가 전체 Ant Design 저장소를 클론할 필요가 없음
MCP 서버 시작 속도가 더 빠름
패키지 크기가 더 작음
새 버전이 출시될 때 업데이트가 더 쉬움
Ant Design 문서를 업데이트하려면 다음을 실행하세요:
npx @jzone-mcp/antd-components-mcp extract [ant design repo path]
graph TD
%% Main modules
Server[MCP Server] --> Tools
Server[MCP Server] --> Prompts
%% Prompt modules
subgraph Prompts[Prompt Modules]
SystemDescription[system-description]
SystemPagesGenerate[system-pages-generate]
end
%% Tool modules
subgraph Tools[Tool Modules]
ListComponents[list-components]
GetDocs[get-component-docs]
ListExamples[list-component-examples]
GetChangelog[get-component-changelog]
end
%% Tool utility functions
Tools --> Utils
subgraph Utils[Utility Functions]
Components[components.ts]
Cache[cache.ts]
MdExtract[md-extract.ts]
MatterParse[matter-parse.ts]
Write[write.ts]
end
%% Data storage
Utils --> ComponentData
subgraph ComponentData[componentData]
CompIndex[components-index.json]
CompChangelog[components-changelog.json]
MetaData[metadata.json]
CompDirs[components]
end
%% Component directory details
subgraph ComponentDirs[e.g：alert]
DocFiles[doc.md]
ExampleFiles[examples.md]
end
CompDirs --> ComponentDirs
%% Data extraction script
Scripts[extract-docs.ts] --> ComponentDatasequenceDiagram
participant Client as Client
participant Server as MCP Server
participant Tools as Tool Modules
participant Utils as Utility Functions
participant Data as Component Data
Client->>Server: Request component information
Server->>Tools: Call appropriate tool
Tools->>Utils: Use utility functions
Utils->>Data: Read component data
Data-->>Utils: Return data
Utils-->>Tools: Processed data
Tools-->>Server: Formatted response
Server-->>Client: Return component informationerDiagram
COMPONENTS-INDEX ||--o{ COMPONENT : contains
COMPONENT ||--|| DOC-FILE : has
COMPONENT ||--|| EXAMPLE-FILE : has
COMPONENTS-CHANGELOG ||--o{ COMPONENT : references
COMPONENTS-INDEX {
array components
}
COMPONENT {
string name
string dirName
string title
string subtitle
}
DOC-FILE {
string content
string api
}
EXAMPLE-FILE {
string content
array examples
}
COMPONENTS-CHANGELOG {
object versions
array changes
}flowchart LR
Request[Component Request] --> CacheCheck{Cache Check}
CacheCheck -->|Exists| ReturnCache[Return Cached Data]
CacheCheck -->|Not Exists| ReadFile[Read File]
ReadFile --> ProcessData[Process Data]
ProcessData --> UpdateCache[Update Cache]
UpdateCache --> ReturnData[Return Data]flowchart TD
A[Start] --> B[Trigger Conditions]
B --> |Every Monday at 10 PM| C[Scheduled Trigger]
B --> |Manual Trigger| D[Manual Trigger]
C --> E[Setup Environment]
D --> E
E --> F[Clone Ant Design Repository]
F --> G[Get Version Information]
G --> G1[Get Ant Design Version]
G --> G2[Get Extracted Data Version]
G1 --> H[Check for Updates]
G2 --> H
H --> |Output Debug Info| I[Display Version Information]
H --> J{Versions Match?}
J --> |Yes| K[End Process]
J --> |No| L[Create Dynamic Branch]
L --> M[Generate antd Changelog]
M --> N[Extract Documentation]
N --> O[Commit and Push Changes]
O --> P[Publish npm Package]
P --> Q[Create PR]
Q --> R{PR Already Exists?}
R --> |Yes| S[Log Existing PR]
R --> |No| T[Create New PR]
S --> K
T --> K列出 Ant Design 特定组件的更新日志 适用场景：
用户询问特定组件的更新日志
在知道用户 antd 版本的情况下，当用户需要实现相关组件功能时判断是否在后续版本中才实现，来决定是否需要升级依赖
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While it mentions the tool lists changelogs, it doesn't disclose behavioral traits like whether it returns full or partial changelogs, how it handles invalid component names, if there are rate limits, or what format the output takes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized with two clear usage scenarios. It's front-loaded with the core purpose, followed by specific contexts. While efficient, the second scenario sentence is somewhat lengthy but still earns its place by providing valuable context.
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 has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers purpose and usage well but lacks critical information about parameters, return values, and behavioral constraints. For a tool with this complexity level, more comprehensive documentation is needed.
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 has 1 parameter with 0% description coverage, and the description doesn't mention the 'componentName' parameter at all. While it implies a component is needed ('特定组件'), it provides no guidance on parameter format, valid values, or semantics. With low schema coverage, the description fails to compensate for the documentation gap.
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 as '列出 Ant Design 特定组件的更新日志' (list changelog for specific Ant Design components), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-component-docs' or 'list-components', which might also provide component-related information but for different purposes.
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 explicit usage scenarios: '用户询问特定组件的更新日志' (when users ask about specific component changelogs) and '在知道用户 antd 版本的情况下...来决定是否需要升级依赖' (when knowing the user's antd version to decide if dependency upgrade is needed for functionality). This clearly indicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Ant Design 特定组件的详细文档 适用场景：
用户询问如何使用特定组件
用户需要查看该组件的 api 属性
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes |
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. The description only states what the tool does (get documentation) but doesn't disclose any behavioral traits such as whether it requires authentication, has rate limits, returns structured data vs. raw text, or handles errors. For a 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 appropriately sized and front-loaded: it starts with the main purpose, followed by usage scenarios in a bullet-like format. Every sentence earns its place by providing essential information. However, it could be slightly more structured (e.g., separating scenarios with clearer formatting) for a perfect 5.
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 (simple lookup with 1 parameter), no annotations, no output schema, and low schema coverage, the description is minimally adequate. It covers the purpose and usage scenarios but lacks details on parameters, behavior, and output. It's complete enough for basic understanding but has clear gaps that could hinder effective use.
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 has 1 parameter with 0% description coverage, meaning the parameter 'componentName' is undocumented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain what 'componentName' should be (e.g., valid component names, format, case sensitivity). With low schema coverage (<50%), the description fails to compensate, leaving the parameter semantics unclear.
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: '获取 Ant Design 特定组件的详细文档' (Get detailed documentation for specific Ant Design components). It specifies the verb ('获取' - get) and resource ('Ant Design 特定组件的详细文档' - detailed documentation for specific Ant Design components). However, it doesn't explicitly differentiate from sibling tools like 'list-components' or 'get-component-changelog', 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 clear usage scenarios: '适用场景：1. 用户询问如何使用特定组件 2. 用户需要查看该组件的 api 属性' (Applicable scenarios: 1. When users ask how to use a specific component 2. When users need to view the component's API properties). This gives good context for when to use the tool. However, it doesn't explicitly mention when NOT to use it or name alternatives like 'list-component-examples' for examples instead of documentation, which would be needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Ant Design 特定组件的代码示例 适用场景：
用户询问特定组件的示例时
用户想要实现某个功能时直接告知可使用的例子
生成页面前需要获取组件的示例代码
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes |
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. While it states what the tool does, it doesn't describe important behavioral traits like whether this is a read-only operation, what format the examples come in (e.g., code snippets, full implementations), whether there are rate limits, or what happens if the component doesn't exist. For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized with three bullet points that efficiently cover usage scenarios. It's front-loaded with the core purpose statement. While the bullet points could be slightly more concise, there's minimal wasted text and the structure helps with readability.
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 (single parameter, no output schema, no annotations), the description provides adequate purpose and usage context but lacks important details about parameters, return values, and behavioral characteristics. It's complete enough to understand when to use the tool but insufficient for reliable invocation without additional assumptions.
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 1 parameter with 0% description coverage, and the tool description doesn't mention the 'componentName' parameter at all. While the description implies a component name is needed ('特定组件'), it doesn't explain what format this should be in, whether it's case-sensitive, or provide any examples. With low schema coverage, the description fails to compensate for the parameter documentation gap.
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 as '获取 Ant Design 特定组件的代码示例' (Get code examples for specific Ant Design components), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-component-docs' or 'list-components', which likely serve related but different purposes.
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 three explicit usage scenarios in Chinese: when users ask for component examples, when users want to implement functionality with examples, and when generating pages needing component code. This gives clear context for when to use the tool. However, it doesn't mention when NOT to use it or explicitly name alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当用户请求一个新的用户界面（UI）使用 Ant Design 组件时使用此工具。 此工具仅返回可用的组件列表。 调用此工具后，你必须编辑或添加文件，以便将代码片段集成到代码库中
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool '仅返回可用的组件列表' (returns only the available component list), which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or returns structured data. The second sentence about editing files adds confusion as it describes post-call actions, not the tool's behavior itself, leaving gaps 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 two sentences, but the second sentence ('调用此工具后，你必须编辑或添加文件...') is somewhat redundant and adds unnecessary detail about post-call actions, diluting focus. It's front-loaded with the primary purpose, but could be more concise by omitting the implementation guidance, which doesn't directly help tool selection.
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, no output schema, and 0 parameters, the description is moderately complete. It covers the purpose and usage context well, but lacks details on return values (e.g., list format) and behavioral aspects like error handling. For a simple list tool, this is adequate but has clear gaps in transparency and output 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the lack of parameters. A baseline score of 4 is applied as per rules for 0 parameters, as it doesn't need to compensate for any schema 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 tool's purpose: '仅返回可用的组件列表' (returns only the available component list). It specifies the resource (Ant Design components) and distinguishes it from siblings like get-component-docs or list-component-examples by focusing on listing rather than documentation or examples. However, it doesn't explicitly mention the verb 'list' in the first sentence, slightly reducing specificity.
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 explicit usage guidelines: '当用户请求一个新的用户界面（UI）使用 Ant Design 组件时使用此工具' (use this tool when the user requests a new UI using Ant Design components). It implies an alternative workflow (editing/adding files after calling) and distinguishes from siblings by focusing on initial listing rather than detailed docs or examples, though it doesn't name alternatives directly.
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-component-changelogget-component-docslist-component-exampleslist-componentsScored across 4 tools
Each tool has a clearly distinct purpose: get-component-changelog retrieves version history, get-component-docs provides API documentation, list-component-examples shows code samples, and list-components enumerates available components. There is no overlap in functionality, and an agent can easily distinguish between them based on their specific use cases.
All tool names follow a consistent verb_noun pattern with hyphens: get-component-changelog, get-component-docs, list-component-examples, and list-components. The verbs 'get' and 'list' are used appropriately, and the naming structure is uniform throughout the set.
With 4 tools, this server is well-scoped for its purpose of providing Ant Design component information. Each tool serves a distinct and essential function (changelog, docs, examples, listing), and there are no extraneous tools. The count is appropriate for the domain, allowing comprehensive coverage without bloat.
The tool set covers key aspects of Ant Design components: listing, documentation, examples, and changelogs. This supports common developer workflows like learning, implementing, and upgrading. A minor gap is the lack of tools for searching or filtering components, but the core needs are well-addressed, and agents can work effectively with the provided tools.
Unofficial MCP server for the Ionic Framework documentation, components and blog.
MCP server for accessing curated awesome list documentation
MCP server for querying Forkast documentation
Dive into the world of npm with our NPM Package Info MCP. Access crucial metadata about any npm
