Element-UI MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have unclear boundaries and significant overlap. For example, get_component already includes events, props, slots, and examples in its output, making get_component_events, get_component_props, get_component_slots, and get_component_examples largely redundant. This creates ambiguity for an agent trying to select the right tool, as it might not know when to use the comprehensive get_component versus the specific sub-tools.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, with all tools using snake_case and starting with 'get_' or 'list_' or 'search_' followed by a clear noun. This predictability makes it easy for an agent to understand and navigate the tool set without confusion.
Tool Count3/5
With 8 tools, the count is borderline for the server's purpose of accessing Element-UI component information. While it covers various aspects, the redundancy among tools makes it feel heavy and over-specified, as a more streamlined set could achieve the same functionality with fewer tools, reducing complexity for agents.
Completeness4/5
The tool set provides comprehensive coverage for retrieving and searching Element-UI component details, including listings, searches, and detailed breakdowns of properties, events, slots, and examples. A minor gap is the lack of tools for creating, updating, or deleting components, but this is reasonable given the server's likely read-only documentation focus, so agents can still perform core lookup tasks effectively.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 mentions '直接返回过滤后的文档内容' (directly return filtered documentation content), which hints at read-only behavior and filtering, but doesn't disclose important behavioral traits like whether this requires authentication, rate limits, error conditions, or what 'filtered' specifically means. For a tool with no annotation coverage, this is insufficient behavioral disclosure.
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 concise with two clear sentences. The first sentence states the purpose, and the second provides behavioral context about returning filtered content. There's no wasted verbiage, though it could be slightly more structured with explicit separation of purpose and behavior.
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 has an output schema (which means the description doesn't need to explain return values) and 100% schema coverage, the description is minimally complete. However, for a tool with no annotations and multiple sibling alternatives, it should provide more context about when to use it and what 'filtered documentation content' specifically entails. The presence of an output schema raises the baseline, but the lack of usage guidance keeps this from being fully complete.
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 meaningful parameter semantics beyond what the schema already provides. With high schema coverage, the baseline score of 3 is appropriate.
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 specific usage examples for Element-UI components). It specifies the verb ('获取' - get) and resource ('Element-UI 组件的具体使用示例' - Element-UI component usage examples). However, it doesn't explicitly differentiate from sibling tools like 'get_component' which might return general documentation rather than examples.
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 alternatives. With sibling tools like 'get_component', 'get_component_props', and 'search_components', there's no indication of when examples are needed versus general documentation, properties, or search functionality. The description only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool retrieves property information but doesn't describe the return format (though an output schema exists, which helps), error handling (e.g., for invalid component names), or performance aspects (e.g., if it's a read-only operation, which is implied but not explicit). For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond basic functionality.
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 a single, efficient sentence in Chinese that clearly states the tool's purpose and what information it returns. It's front-loaded with the main action and includes specific details (name, type, description, default value). There's no wasted verbiage, though it could be slightly more structured for 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 (2 parameters, 1 required), 100% schema coverage, and the presence of an output schema, the description is minimally adequate. It explains what the tool does but lacks usage guidelines, behavioral details (e.g., error cases), and differentiation from siblings. The output schema mitigates the need to describe return values, but overall completeness is limited to basic functionality.
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 schema description coverage is 100%, with clear descriptions for both parameters: 'tagName' (component tag name, e.g., el-button) and 'propName' (specific property name, optional to return all). The description adds minimal value beyond the schema, mentioning 'Element-UI 组件' to contextualize the tagName but not elaborating on parameter usage or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 组件的所有属性（Props）信息，包括名称、类型、描述、默认值等' (Get all property information for Element-UI components, including name, type, description, default value, etc.). It specifies the verb ('获取' - get) and resource ('Element-UI 组件的所有属性' - all properties of Element-UI components). However, it doesn't explicitly differentiate from sibling tools like 'get_component' (which might get general component info) or 'get_component_events' (which gets events).
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 alternatives. It doesn't mention sibling tools like 'get_component' (for general info), 'get_component_events' (for events), or 'list_components' (for listing components). There's no context about prerequisites, such as needing a valid component name, or exclusions. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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. It states the tool returns method information including name, parameters, and return values, but doesn't cover other important aspects like whether it's a read-only operation (implied but not stated), error handling, rate limits, authentication needs, or response format details. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose and what information it returns. It's front-loaded with the core function and avoids unnecessary details. However, it could be slightly more structured by explicitly separating input and output aspects.
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 defines the tool's scope (Element-UI component methods) and output content. However, it lacks behavioral context (e.g., error cases, permissions) and usage guidelines relative to siblings, which are minor gaps.
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 schema description coverage is 100%, so the schema already documents both parameters ('tagName' and 'methodName') with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema—it mentions '方法名称、参数、返回值等' (method name, parameters, return values, etc.), but this refers to output, not input parameters. 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 组件的所有方法（Methods）信息' (Get all method information for Element-UI components). It specifies the resource (Element-UI components) and verb (get methods), but doesn't explicitly distinguish it from sibling tools like 'get_component' or 'get_component_props' beyond mentioning it's for methods specifically.
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 alternatives. It doesn't mention sibling tools like 'get_component' (which might return general component info) or 'get_component_events' (for events instead of methods), nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions fuzzy matching in component names and descriptions, which adds some context, but doesn't cover other important aspects like whether this is a read-only operation, what the output format is, if there are rate limits, or any error conditions. For a search tool with zero annotation coverage, this is insufficient.
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 appropriately sized and front-loaded: it's a single, efficient sentence that directly states the purpose and key feature (fuzzy matching). Every word earns its place, with no redundancy or unnecessary details.
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 that there is an output schema (which covers return values), the description doesn't need to explain outputs. However, with no annotations and a search tool that likely has behavioral nuances (e.g., search scope, result ordering), the description is minimal. It's adequate for a basic search but lacks depth for more complex usage scenarios.
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 schema description coverage is 100%, so the schema already documents both parameters ('keyword' and 'limit') with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the fuzzy matching algorithm or default behavior for 'limit'. 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 组件库中的组件' (search Element-UI component library components by keyword). It specifies the verb '搜索' (search) and resource 'Element-UI 组件库中的组件' (Element-UI component library components), but doesn't explicitly differentiate from sibling tools like 'list_components' or 'get_component', which is why it doesn't reach a 5.
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 alternatives. It mentions '支持在组件名和描述中进行模糊匹配' (supports fuzzy matching in component names and descriptions), which hints at context, but doesn't specify when to choose this over 'list_components' or 'get_component', nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'get'), potential rate limits, authentication needs, or error conditions. The description is minimal on behavioral context.
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 directly states the tool's purpose and scope. It's front-loaded with the core action and includes no unnecessary information, making it highly concise and well-structured.
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 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, though it lacks behavioral details that would be helpful without annotations.
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 adds no additional parameter semantics beyond what's in the schema (e.g., no examples, format details, or edge cases). 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 sibling tools like get_component_methods and get_component_props by focusing exclusively on events.
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 when needing event information for Element-UI components, but doesn't explicitly state when to use this vs. alternatives like get_component (which might provide broader info) or when not to use it. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![element-ui-mcp MCP server](https://glama.ai/mcp/servers/yun8711/element-ui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yun8711/element-ui-mcp)

Score Badge

Copy to your README.md:

[![element-ui-mcp MCP server](https://glama.ai/mcp/servers/yun8711/element-ui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yun8711/element-ui-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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