Skip to main content
Glama
yun8711

Element-UI MCP Server

by yun8711

List Element-UI Components

list_components

Retrieve a sorted catalog of all available Element-UI components with their tag names, descriptions, and documentation URLs for Vue 2 development.

Instructions

列出 Element-UI 组件库中所有可用的组件。每个条目返回:含前缀的标签名(tagName)、描述(description)、文档 URL(documentation URL)。结果按标签名(升序)排序。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
componentsYes一份包含组件及其标签名称、描述、文档 URL 的列表(按标签名称排序)。

Implementation Reference

  • The handler function that lists all Element-UI components by mapping from componentObject data, returning structured content and JSON text.
    async () => {
      const components = Object.values(componentObject)
      const list = components.map(component => ({
        tagName: component.tagName,
        description: component.description,
        docUrl: component.docUrl,
      }))
    
      return {
        structuredContent: { components: list },
        content: [
          {
            type: 'text' as const,
            text: JSON.stringify({ components: list }, null, 2),
          },
        ],
      }
    }
  • Input schema (empty) and output schema defining an array of components with tagName, description, and docUrl.
    inputSchema: {},
    outputSchema: {
      components: z
        .array(
          z.object({
            tagName: z.string().describe('组件标签名, 例如:el-button'),
            description: z.string().describe('组件描述'),
            docUrl: z.string().url().describe('组件文档URL'),
          })
        )
        .describe(
          '一份包含组件及其标签名称、描述、文档 URL 的列表(按标签名称排序)。'
        ),
    },
  • The registerListComponents function that registers the 'list_components' tool with the MCP server, including schema and handler.
    export function registerListComponents(server: McpServer) {
      server.registerTool(
        'list_components',
        {
          title: 'List Element-UI Components',
          description:
            '列出 Element-UI 组件库中所有可用的组件。每个条目返回:含前缀的标签名(tagName)、描述(description)、文档 URL(documentation URL)。结果按标签名(升序)排序。',
          inputSchema: {},
          outputSchema: {
            components: z
              .array(
                z.object({
                  tagName: z.string().describe('组件标签名, 例如:el-button'),
                  description: z.string().describe('组件描述'),
                  docUrl: z.string().url().describe('组件文档URL'),
                })
              )
              .describe(
                '一份包含组件及其标签名称、描述、文档 URL 的列表(按标签名称排序)。'
              ),
          },
        },
        async () => {
          const components = Object.values(componentObject)
          const list = components.map(component => ({
            tagName: component.tagName,
            description: component.description,
            docUrl: component.docUrl,
          }))
    
          return {
            structuredContent: { components: list },
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({ components: list }, null, 2),
              },
            ],
          }
        }
      )
    }
  • src/index.ts:29-29 (registration)
    Invocation of registerListComponents in the main server creation function.
    registerListComponents(server);
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well. It discloses key behavioral traits: returns specific fields (tagName with prefix, description, documentation URL), sorting behavior (ascending by tagName), and scope (all components). It doesn't mention pagination, rate limits, or authentication needs, but for a simple list tool this is reasonable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with zero waste. First sentence states purpose, second specifies return format and sorting. Every element earns its place, and the description is appropriately sized for this simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 annotations, but has output schema), the description is complete. It explains what the tool does, what it returns, and how results are organized. With an output schema handling return structure details, the description doesn't need to explain return values further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on output behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('列出' - list) and resource ('Element-UI 组件库中所有可用的组件' - all available components in Element-UI component library). It distinguishes from siblings by specifying it returns ALL components with specific fields, unlike get_component (single component) or search_components (filtered results).

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 implies when to use it (to get ALL components with tagName, description, and documentation URL). However, it doesn't explicitly state when NOT to use it or name alternatives like get_component for single components or search_components for filtered results. The context is clear but lacks explicit exclusions.

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/yun8711/element-ui-mcp'

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