Provides comprehensive access to the Ant Design component library, allowing users to retrieve component names, detailed API documentation, props, and code examples for automated UI development.
简体中文 | English
一个 Model Context Protocol (MCP) 服务器，提供 Ant Design 组件库的文档和信息访问，用于自动化代码生成。
📋 获取所有可用的 Ant Design 组件名称
📖 获取详细的组件信息（props、示例、API 文档）
🔍 通过关键词或类别搜索组件
💡 获取特定组件的使用示例
🏷️ 按类别浏览组件
Related MCP server: antd-components-mcp
npm install -g ant-design-mcpnpm install ant-design-mcpnpx ant-design-mcp添加到您的 Claude Desktop 配置文件：
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"ant-design": {
"command": "npx",
"args": ["-y", "ant-design-mcp"]
}
}
}如果已全局安装：
{
"mcpServers": {
"ant-design": {
"command": "ant-design-mcp"
}
}
}npm startnpm run dev获取所有可用的 Ant Design 组件名称列表。
返回值: 以逗号分隔的所有组件名称字符串
示例:
Button, Form, Table, Modal, Input, Select, ...获取特定组件的详细信息。
参数:
componentName (string, 必需): 组件名称（例如 "Button"、"Form"）
返回值: 包含以下内容的 Markdown 文档:
组件类别
描述
导入语句
Props 文档
使用示例
API 文档 URL
通过关键词或功能搜索组件。
参数:
keyword (string, 必需): 搜索词（组件名称、类别或功能）
返回值: 匹配的组件列表及描述
获取特定组件的完整使用示例。
参数:
componentName (string, 必需): 组件名称
返回值: TypeScript/React 代码示例
获取特定类别中的所有组件。
参数:
category (string, 必需): 类别名称
General (通用)
Layout (布局)
Navigation (导航)
Data Entry (数据录入)
Data Display (数据展示)
Feedback (反馈)
Other (其他)
返回值: 指定类别中的组件名称列表
获取所有可用的 @ant-design/icons 图标名称列表。
返回值: 以逗号分隔的所有图标名称字符串（包含 750+ 个图标）
示例:
StepBackwardOutlined, StepForwardOutlined, CheckCircleOutlined, CloseCircleOutlined, ...图标类型:
Outlined (线框风格)
Filled (实心风格)
TwoTone (双色风格)
Button, Icon, Typography
Divider, Grid, Layout, Space, Splitter
Affix, Breadcrumb, Dropdown, Menu, Pagination, Steps
AutoComplete, Cascader, Checkbox, ColorPicker, DatePicker, Form, Input, InputNumber, Mentions, Radio, Rate, Select, Slider, Switch, TimePicker, Transfer, TreeSelect, Upload
Avatar, Badge, Calendar, Card, Carousel, Collapse, Descriptions, Empty, Image, List, Popover, QRCode, Segmented, Statistic, Table, Tabs, Tag, Timeline, Tooltip, Tour, Tree
Alert, Drawer, Message, Modal, Notification, Popconfirm, Progress, Result, Skeleton, Spin, Watermark
Anchor, App, ConfigProvider, FloatButton, Flex
添加到您的 Claude Desktop 配置：
{
"mcpServers": {
"ant-design": {
"command": "node",
"args": ["/path/to/ant-admin-template/ant-design-mcp/index.js"]
}
}
}自动化代码生成: 使用组件信息从设计规范自动生成 React 代码
组件发现: 快速找到满足需求的合适组件
文档参考: 无需离开开发环境即可访问组件 props 和示例
设计系统集成: 将 Ant Design 组件集成到 AI 驱动的开发工作流程中
"获取所有 Ant Design 组件名称"
"显示 Form 组件的信息"
"搜索与数据录入相关的组件"
"获取 Table 组件的使用示例"
"显示反馈类别中的所有组件"
要添加更详细的组件信息：
Fork 仓库
编辑 index.js
在 COMPONENT_INFO 对象中添加组件详情
包含 props、示例和描述
提交 pull request
# 克隆仓库
git clone https://github.com/leonwgc/ant-design-mcp.git
cd ant-design-mcp
# 安装依赖
npm install
# 以开发模式运行（自动重载）
npm run dev详细的发布说明请参阅 PUBLISH.md
ISC
leon.wang
Get a list of all available Ant Design component names. Returns all component names as a comma-separated string.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden: it specifies zero parameters, returns a comma-separated string of all component names, and implies no side effects. No behavioral ambiguity.
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?
Two sentences: first states action, second states output format. No wasted words, directly front-loaded with key 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 no parameters and no output schema, description fully covers behavior: it lists all component names as a string. No additional context needed for correct 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?
Tool has zero parameters, so schema coverage is trivially 100%. Description adds meaning by confirming no input is needed and specifying output format, which is beyond the schema's empty definition.
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?
Description clearly states it gets all available Ant Design component names and returns them as a comma-separated string. This distinguishes it from sibling tools like get_all_icon_names (icons) and search_components (search/filtered), making purpose unambiguous.
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 alternatives are mentioned. However, the action 'get all' implies usage when a complete list is needed, distinguishing from search or category-based retrieval through context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all available Ant Design Icons from @ant-design/icons package. Returns all icon names as a comma-separated string.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: returns all icon names as comma-separated string. Being a read-only, zero-parameter tool, there are no side effects or constraints to disclose.
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?
Two concise sentences that front-load the purpose and output format. Every word is necessary and informative.
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?
For a zero-parameter, no-output-schema tool, the description provides all necessary information: action, resource, source, and return format. Complete and sufficient.
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 trivially 100%. The description adds no parameter info, but baseline for 0 params is 4. No further detail needed.
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 'Get a list of all available Ant Design Icons', specifies the source package, and notes return format as comma-separated string. It distinguishes from sibling tools that focus on components.
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: retrieve all icon names. No explicit when-to-use or alternatives, but sibling context (component tools) makes it clear. Lacks explicit guidance but adequate for simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a complete usage example for a specific Ant Design component with TypeScript and React code.
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | The name of the Ant Design component |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must detail behavioral traits. It only says 'complete usage example' without specifics on what completeness means (e.g., includes imports, full code, or just a snippet), nor any constraints or additional 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 a single sentence that is concise and front-loaded. It gets the point across without waste, but could be slightly more informative without losing conciseness.
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?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and output. It mentions TypeScript and React, adding relevant context. However, it could be more precise about the format of the example.
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 the parameter. The description adds no extra meaning beyond 'the name of the Ant Design component', not specifying casing or format. 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 verb 'Get' and the specific resource 'a complete usage example for a specific Ant Design component with TypeScript and React code', differentiating it from sibling tools like get_component_info which likely returns metadata, not code examples.
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 does not explicitly state when to use this tool versus alternatives like get_component_info or search_components. Usage is implied from the purpose, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Ant Design component including description, props, usage examples, and API documentation URL.
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | The name of the Ant Design component (e.g., "Button", "Form", "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. It discloses the returned information categories (description, props, etc.), but does not mention if the tool performs network requests, requires authentication, or has any side effects. Adequate but not exhaustive.
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 conveying all essential information without redundancy. No unnecessary words; every phrase is functional.
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 (1 parameter, no output schema), the description covers the core purpose and return content. Minor omission: does not explicitly state that the tool is read-only or mention error behavior, but overall sufficient.
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% (componentName with description and example). The description adds no additional semantic meaning beyond what the schema already provides. Baseline score applies.
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 explicitly states the tool's purpose: retrieving detailed component information (description, props, usage examples, API URL). This clearly distinguishes it from sibling tools like get_all_component_names or get_component_example.
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 a specific component name is known, but does not explicitly state when to avoid it (e.g., for listing all components) or note alternatives. However, sibling context provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all components in a specific category (General, Layout, Navigation, Data Entry, Data Display, Feedback, Other).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Component category (General, Layout, Navigation, Data Entry, Data Display, Feedback, Other) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic action. It omits whether it returns full component objects or just names, any pagination behavior, or auth requirements. 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 a single sentence that conveys all necessary information without any wasted words. It is front-loaded and efficient.
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 parameter, no output schema), the description is mostly adequate but lacks mention of the return format (e.g., names, full component data). The list of categories aids use but does not fully compensate for the missing output details.
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%, and the tool description adds no new semantics beyond the schema. The parameter description is effectively identical. 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 action ('get all components') and the filter ('in a specific category'), with explicit list of valid categories. This distinguishes it from siblings like get_all_component_names (no filter) and search_components (search-based).
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 you need components by category, but does not explicitly contrast with alternatives (e.g., 'use get_all_component_names for unfiltered list'). The lack of explicit when-not or alternative guidance prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Ant Design components by keyword or category. Returns matching component names and brief descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword (component name, category, or feature) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only states that it returns matching names and descriptions, but omits details like search algorithm (fuzzy vs exact), result limits, case sensitivity, or ordering. This is insufficient for a reliable agent decision.
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?
Two sentences with no redundancy. The first sentence provides the primary action and search scope, the second states the output. Highly efficient and front-loaded.
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?
For a simple single-parameter tool without output schema, the description adequately covers purpose and output. It lacks some behavioral details but is mostly complete given the tool's simplicity. A more comprehensive description could mention result limits or search behavior.
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%, so baseline is 3. The description adds value by explaining the return format (component names and brief descriptions) and clarifying that keyword can be a name, category, or feature, which aligns with the schema description. This extra context justifies a 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 specifies the action (search), resource (Ant Design components), and search dimensions (keyword or category). It distinguishes from siblings like get_components_by_category by implying this tool handles more varied input (keyword including category) and returns brief descriptions, while siblings are more focused.
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 guidance on when to use this tool versus alternatives like get_components_by_category or get_all_component_names. The description does not state use cases or exclusion criteria, leaving the agent to infer.
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.2get_all_component_namesget_all_icon_namesget_component_exampleget_component_infoget_components_by_categorysearch_componentsScored across 6 tools
Each tool has a clearly distinct purpose: listing component/icon names, retrieving examples or detailed info, filtering by category, and searching. There is no ambiguity between them.
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_all_component_names, get_component_example, search_components), making them predictable and easy to understand.
With 6 tools, the server is well-scoped for exploring Ant Design components and icons. It covers listing, searching, and retrieving detailed information without being over- or under-inclusive.
The tool surface provides comprehensive coverage for exploring Ant Design: listing all components and icons, retrieving examples and detailed info (including props), searching, and filtering by category. No obvious gaps are present.
Find UI components and themes, retrieve code, and generate with hosted 21st AI when enabled.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Software component catalog: search your org's services, docs, APIs, dependencies, and ownership.
