Skip to main content
Glama
yun8711

Element-UI MCP Server

by yun8711

Get Component Slots

get_component_slots

Retrieve slot information for Element-UI components including slot names, scoped parameters, and descriptions to enable accurate Vue 2 code generation.

Instructions

获取 Element-UI 组件的所有插槽(Slots)信息,包括插槽名称、作用域参数、描述等。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNameYes组件标签名, 例如:el-button
slotNameNo获取特定插槽的名称,不指定则返回所有插槽

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotsYes
totalYes插槽总数
tagNameYes组件标签名

Implementation Reference

  • The asynchronous handler function implementing the core logic of the 'get_component_slots' tool. It retrieves component slots from metadata, filters by slotName if provided, handles missing components/slots with errors listing alternatives, and returns structured JSON content.
      async ({ tagName, slotName }) => {
        const component = componentObject[tagName]
    
        if (!component) {
          throw new Error(`Component "${tagName}" not found. Available components: ${Object.keys(componentObject).join(', ')}`)
        }
    
        let resultSlots = component.slots || []
    
        // 如果指定了插槽名,过滤特定插槽
        if (slotName) {
          resultSlots = resultSlots.filter(slot => slot.name === slotName)
          if (resultSlots.length === 0) {
            throw new Error(`Slot "${slotName}" not found in component "${tagName}". Available slots: ${component.slots?.map(s => s.name).join(', ') || 'none'}`)
          }
        }
    
        const result = {
          tagName,
          slots: resultSlots,
          total: (component.slots || []).length,
        }
    
        return {
          structuredContent: result,
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify(result, null, 2),
            },
          ],
        }
      }
    )
  • Zod-based input and output schemas defining the tool interface: input requires tagName (e.g., 'el-button'), optional slotName; output includes tagName, array of slots (with name, description, parameters, ts), and total count.
    {
      title: 'Get Component Slots',
      description: '获取 Element-UI 组件的所有插槽(Slots)信息,包括插槽名称、作用域参数、描述等。',
      inputSchema: z.object({
        tagName: z.string().describe('组件标签名, 例如:el-button'),
        slotName: z.string().optional().describe('获取特定插槽的名称,不指定则返回所有插槽'),
      }),
      outputSchema: z.object({
        tagName: z.string().describe('组件标签名'),
        slots: z.array(
          z.object({
            name: z.string().describe('插槽名'),
            description: z.string().optional().describe('插槽描述'),
            parameters: z.array(
              z.object({
                raw: z.string().describe('参数类型'),
              })
            ).optional().describe('作用域插槽的参数'),
            ts: z.string().optional().describe('TypeScript 签名'),
          })
        ),
        total: z.number().describe('插槽总数'),
      }),
    },
  • Module-level registration function that registers the 'get_component_slots' tool on the MCP server using server.registerTool with name, schema, and handler.
    export function registerGetComponentSlots(server: McpServer) {
      server.registerTool(
        'get_component_slots',
        {
          title: 'Get Component Slots',
          description: '获取 Element-UI 组件的所有插槽(Slots)信息,包括插槽名称、作用域参数、描述等。',
          inputSchema: z.object({
            tagName: z.string().describe('组件标签名, 例如:el-button'),
            slotName: z.string().optional().describe('获取特定插槽的名称,不指定则返回所有插槽'),
          }),
          outputSchema: z.object({
            tagName: z.string().describe('组件标签名'),
            slots: z.array(
              z.object({
                name: z.string().describe('插槽名'),
                description: z.string().optional().describe('插槽描述'),
                parameters: z.array(
                  z.object({
                    raw: z.string().describe('参数类型'),
                  })
                ).optional().describe('作用域插槽的参数'),
                ts: z.string().optional().describe('TypeScript 签名'),
              })
            ),
            total: z.number().describe('插槽总数'),
          }),
        },
        async ({ tagName, slotName }) => {
          const component = componentObject[tagName]
    
          if (!component) {
            throw new Error(`Component "${tagName}" not found. Available components: ${Object.keys(componentObject).join(', ')}`)
          }
    
          let resultSlots = component.slots || []
    
          // 如果指定了插槽名,过滤特定插槽
          if (slotName) {
            resultSlots = resultSlots.filter(slot => slot.name === slotName)
            if (resultSlots.length === 0) {
              throw new Error(`Slot "${slotName}" not found in component "${tagName}". Available slots: ${component.slots?.map(s => s.name).join(', ') || 'none'}`)
            }
          }
    
          const result = {
            tagName,
            slots: resultSlots,
            total: (component.slots || []).length,
          }
    
          return {
            structuredContent: result,
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify(result, null, 2),
              },
            ],
          }
        }
      )
    }
  • src/index.ts:35-35 (registration)
    Application-level invocation of the tool registration during server setup in the main entry point.
    registerGetComponentSlots(server);
  • src/index.ts:11-11 (registration)
    Import statement for the get_component_slots registration module.
    import { registerGetComponentSlots } from './tools/get-component-slots.js';
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states what information is returned (slot names, scope parameters, descriptions) but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or response format details. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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?

The description is a single, efficient sentence in Chinese that front-loads the core purpose and includes the scope of returned information. Every word earns its place with no redundancy or unnecessary elaboration.

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 (2 parameters, 1 required), 100% schema coverage, and the presence of an output schema (which handles return values), the description is reasonably complete. It clearly states what the tool does and what information it returns. The main gap is the lack of behavioral context due to missing annotations, but the output schema mitigates some of this.

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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (e.g., it doesn't explain format constraints for tagName beyond '例如:el-button' which is already in schema, or clarify slotName behavior further). Baseline 3 is appropriate when schema does the heavy lifting.

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 ('获取' meaning 'get'), resource ('Element-UI 组件的所有插槽'), and scope ('包括插槽名称、作用域参数、描述等'). It distinguishes from siblings like get_component_props (which gets properties) and get_component_events (which gets events) by focusing specifically on slots.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving slot information about Element-UI components, but provides no explicit guidance on when to use this tool versus alternatives like get_component (which might return broader component info) or when not to use it. The context is clear but lacks sibling differentiation or exclusion criteria.

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