Skip to main content
Glama
yun8711

Element-UI MCP Server

by yun8711

Get Element-UI Component

get_component

Retrieve detailed documentation for Element-UI components including properties, events, slots, and example code to support Vue 2 development.

Instructions

获取 Element-UI 组件库中某个组件的详细信息。返回:含前缀的标签名(tagName)、描述(description)、文档 URL(documentation URL)、属性(props)、事件(events)、插槽(slots)、示例代码(example)、类型定义(dts)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNameYes组件标签名, 例如:el-button

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dtsYes组件的TypeScript类型定义
propsNo组件属性列表
slotsNo组件插槽列表
docUrlYes组件文档URL
eventsNo组件事件(Events)列表
methodsNo组件方法(Methods)列表
tagNameYes组件标签名, 例如:el-button
examplesYes组件用法示例文档内容
descriptionYes组件描述

Implementation Reference

  • The core handler logic for the 'get_component' tool. It retrieves component data from the componentObject, reads optional example Markdown and TypeScript definition files, assembles the result, and returns structured JSON content.
      async ({ tagName }) => {
        const component = componentObject[tagName]
    
        if (!component) {
          throw new Error(`Component "${tagName}" not found. Available components: ${Object.keys(componentObject).join(', ')}`)
        }
    
        // 读取示例代码(MD文件)
        let examples = ''
        try {
          const mdPath = path.join(__dirname, '../data/docs', `${tagName}.md`)
          if (fs.existsSync(mdPath)) {
            examples = fs.readFileSync(mdPath, 'utf8')
          }
        } catch (error) {
          console.warn(`Failed to read examples for ${tagName}:`, error)
        }
    
        // 读取类型定义(DTS文件)
        let dts = ''
        try {
          const dtsPath = path.join(__dirname, '../examples', `${tagName}.d.ts`)
          if (fs.existsSync(dtsPath)) {
            dts = fs.readFileSync(dtsPath, 'utf8')
          }
        } catch (error) {
          console.warn(`Failed to read dts for ${tagName}:`, error)
        }
    
        const result = {
          tagName: component.tagName,
          description: component.description,
          docUrl: component.docUrl,
          props: component.props || [],
          events: component.events || [],
          slots: component.slots || [],
          methods: component.methods || [],
          examples,
          dts: dts,
        }
    
        return {
          structuredContent: result,
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify(result, null, 2),
            },
          ],
        }
      }
    )
  • Input and output schemas defined using Zod for the 'get_component' tool, specifying the tagName input and detailed output structure for component information.
    {
      title: 'Get Element-UI Component',
      description:
        '获取 Element-UI 组件库中某个组件的详细信息。返回:含前缀的标签名(tagName)、描述(description)、文档 URL(documentation URL)、属性(props)、事件(events)、插槽(slots)、示例代码(example)、类型定义(dts)。',
      inputSchema: z.object({
        tagName: z.string().describe('组件标签名, 例如:el-button'),
      }),
      outputSchema: z.object({
        tagName: z.string().describe('组件标签名, 例如:el-button'),
        description: z.string().describe('组件描述'),
        docUrl: z.string().url().describe('组件文档URL'),
        props: z.any().describe('组件属性列表'),
        slots: z.any().describe('组件插槽列表'),
        methods: z.any().describe('组件方法(Methods)列表'),
        events: z.any().describe('组件事件(Events)列表'),
        examples: z.string().describe('组件用法示例文档内容'),
        dts: z.string().describe('组件的TypeScript类型定义'),
      }),
    },
  • The registerGetComponent function that registers the 'get_component' tool on the MCP server, including title, description, schemas, and handler.
    export function registerGetComponent(server: McpServer) {
      server.registerTool(
        'get_component',
        {
          title: 'Get Element-UI Component',
          description:
            '获取 Element-UI 组件库中某个组件的详细信息。返回:含前缀的标签名(tagName)、描述(description)、文档 URL(documentation URL)、属性(props)、事件(events)、插槽(slots)、示例代码(example)、类型定义(dts)。',
          inputSchema: z.object({
            tagName: z.string().describe('组件标签名, 例如:el-button'),
          }),
          outputSchema: z.object({
            tagName: z.string().describe('组件标签名, 例如:el-button'),
            description: z.string().describe('组件描述'),
            docUrl: z.string().url().describe('组件文档URL'),
            props: z.any().describe('组件属性列表'),
            slots: z.any().describe('组件插槽列表'),
            methods: z.any().describe('组件方法(Methods)列表'),
            events: z.any().describe('组件事件(Events)列表'),
            examples: z.string().describe('组件用法示例文档内容'),
            dts: z.string().describe('组件的TypeScript类型定义'),
          }),
        },
        async ({ tagName }) => {
          const component = componentObject[tagName]
    
          if (!component) {
            throw new Error(`Component "${tagName}" not found. Available components: ${Object.keys(componentObject).join(', ')}`)
          }
    
          // 读取示例代码(MD文件)
          let examples = ''
          try {
            const mdPath = path.join(__dirname, '../data/docs', `${tagName}.md`)
            if (fs.existsSync(mdPath)) {
              examples = fs.readFileSync(mdPath, 'utf8')
            }
          } catch (error) {
            console.warn(`Failed to read examples for ${tagName}:`, error)
          }
    
          // 读取类型定义(DTS文件)
          let dts = ''
          try {
            const dtsPath = path.join(__dirname, '../examples', `${tagName}.d.ts`)
            if (fs.existsSync(dtsPath)) {
              dts = fs.readFileSync(dtsPath, 'utf8')
            }
          } catch (error) {
            console.warn(`Failed to read dts for ${tagName}:`, error)
          }
    
          const result = {
            tagName: component.tagName,
            description: component.description,
            docUrl: component.docUrl,
            props: component.props || [],
            events: component.events || [],
            slots: component.slots || [],
            methods: component.methods || [],
            examples,
            dts: dts,
          }
    
          return {
            structuredContent: result,
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify(result, null, 2),
              },
            ],
          }
        }
      )
    }
  • src/index.ts:6-30 (registration)
    Top-level import and registration call for the 'get_component' tool in the main server setup.
    import { registerGetComponent } from './tools/get-component.js';
    import { registerSearchComponents } from './tools/search-components.js';
    import { registerGetComponentExamples } from './tools/get-component-examples.js';
    import { registerGetComponentProps } from './tools/get-component-props.js';
    import { registerGetComponentEvents } from './tools/get-component-events.js';
    import { registerGetComponentSlots } from './tools/get-component-slots.js';
    import { registerGetComponentMethods } from './tools/get-component-methods.js';
    
    export function createServer() {
      const __filename = fileURLToPath(import.meta.url);
      const __dirname = path.dirname(__filename);
      const VERSION = (
        JSON.parse(
          fs.readFileSync(path.join(__dirname, '../package.json'), 'utf8'),
        ) as { version: string }
      ).version;
    
      const server = new McpServer({
        name: 'element-ui-mcp',
        version: VERSION,
      });
    
      // Register tool modules
      registerListComponents(server);
      registerGetComponent(server);
Behavior2/5

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 states what information is returned but doesn't cover important behavioral aspects: it doesn't mention error handling (e.g., what happens if tagName doesn't exist), performance characteristics, authentication needs, or rate limits. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic output.

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 efficiently structured in two sentences: one stating the purpose and one listing the return fields. Every element serves a purpose—the return field list helps the agent understand the comprehensive nature of this tool versus its siblings. However, it could be slightly more front-loaded by explicitly contrasting with sibling tools earlier.

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

Completeness4/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, comprehensive output), the description is reasonably complete. The presence of an output schema means the description doesn't need to detail return values, and the 100% schema coverage handles parameters adequately. However, the lack of behavioral context (error handling, etc.) and usage guidance relative to siblings prevents a perfect score.

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

Parameters3/5

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 'tagName' clearly documented as '组件标签名, 例如:el-button' (component tag name, e.g., el-button). The description doesn't add any parameter semantics beyond what the schema already provides—it doesn't explain format constraints, provide additional examples, or clarify the '含前缀的标签名' (tag name with prefix) mentioned in the return values. Baseline 3 is appropriate when the schema does the heavy lifting.

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: '获取 Element-UI 组件库中某个组件的详细信息' (Get detailed information about a component in the Element-UI component library). It specifies the verb ('获取' - get) and resource ('组件' - component), but doesn't explicitly differentiate it from sibling tools like get_component_props or get_component_events, which focus on specific aspects rather than comprehensive details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 its siblings. It doesn't mention alternatives like using get_component_props for just properties or list_components for browsing, nor does it specify prerequisites or contextual usage scenarios. The agent must infer usage from tool names alone.

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