Skip to main content
Glama

list-component-examples

Get code examples for Ant Design components to implement UI features or understand component usage patterns.

Instructions

获取 Ant Design 特定组件的代码示例 适用场景:

  1. 用户询问特定组件的示例时

  2. 用户想要实现某个功能时直接告知可使用的例子

  3. 生成页面前需要获取组件的示例代码

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
componentNameYes

Implementation Reference

  • The MCP tool handler that invokes the helper to fetch component examples and formats the response as structured MCP content.
        async ({ componentName }) => {
          const componentExamples = await listComponentExamples(componentName);
      
          return {
            content: [
              {
                type: "text",
                text: `${componentName} 组件的代码示例文档:
    ${componentExamples || '暂无代码示例'}`,
              },
            ],
          };
        },
  • Input schema using Zod, requiring a 'componentName' string parameter.
    { componentName: z.string() },
  • The tool registration function that attaches the tool to the MCP server, including name, description, schema, and handler.
    const registryTool = (server: McpServer) => {
      server.tool(
        "list-component-examples",
        `获取 Ant Design 特定组件的代码示例
    适用场景:
    1. 用户询问特定组件的示例时
    2. 用户想要实现某个功能时直接告知可使用的例子
    3. 生成页面前需要获取组件的示例代码`,
        { componentName: z.string() },
        async ({ componentName }) => {
          const componentExamples = await listComponentExamples(componentName);
      
          return {
            content: [
              {
                type: "text",
                text: `${componentName} 组件的代码示例文档:
    ${componentExamples || '暂无代码示例'}`,
              },
            ],
          };
        },
      );
    }
  • Higher-level registration that imports and invokes all tool registry functions, including this one.
    import getComponentDocs from "./get-component-docs";
    import listComponentExamples from "./list-component-examples";
    import getComponentChangelog from "./get-component-changelog";
    import listComponents from "./list-components";
    
    export default function registryTools(server: McpServer) {
      [getComponentDocs, listComponentExamples, getComponentChangelog, listComponents].forEach((registryFn) => {
        registryFn(server)
      })
  • Core helper function that locates the component directory, reads the example markdown file from disk (with caching), and returns the content or error message.
    export const listComponentExamples = async (componentName: string) => {
      const component = await findComponentByName(componentName);
    
      if (!component) {
        return "当前组件不存在";
      }
    
      const examplesMdPath = join(EXTRACTED_COMPONENTS_DATA_PATH, component.dirName, EXAMPLE_FILE_NAME);
    
      if (!existsSync(examplesMdPath)) {
        return `${component.name} 的示例代码不存在`;
      }
      try {
        const cacheComponentExample = componentCache.get('componentExample') || {}
        if (cacheComponentExample?.[component.name]) {
          return cacheComponentExample[component.name]
        }
    
        if (existsSync(examplesMdPath)) {
          const exampleResult = await readFile(examplesMdPath, "utf-8");
    
          cacheComponentExample[component.name] = exampleResult
          componentCache.set('componentExample', cacheComponentExample)
    
          return exampleResult
        }
    
        return await readFile(examplesMdPath, "utf-8");
      } catch (error) {
        console.error(`${component.name} 的示例代码不存在: ${(error as Error).message}`);
        return `${component.name} 的示例代码不存在`;
      }
    };
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhixiaoqiang/antd-components-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server