UI System Selector MCP

by MossaJehad

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool addresses a distinct interaction type—retrieval by ID, filtered listing, natural language search, comparison, component guidance, selection state, installation, and recommendation. The only mild overlap is between list, search, and recommend, all returning UI systems, but their query modes differ enough to minimize misselection.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (get_, list_, search_, compare_, select_, clear_, recommend_). Compound names like get_selected_ui_system remain predictable and readable.
Tool Count5/5
10 tools is squarely in the well-scoped range for a UI system selector. Each tool covers a necessary step in discovering, evaluating, selecting, and installing a design system without bloat or redundancy.
Completeness5/5
The server covers the full workflow: discovery (list, search, recommend), deep inspection (get, compare, component guidance, installation), and session state management (select, get selected, clear). There are no obvious dead ends or missing operations for the stated purpose.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List available...' clearly signals a read-only enumeration operation, which is transparent. However, it does not disclose default limit behavior, ordering, or response shape; for a simple list tool this is acceptable but not rich.
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?
A single sentence, front-loaded with the action and resource, and compact enough to be easily parsed. The parenthetical filter list is a reasonable way to convey the optional filtering capability without bloating the description.
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?
The description is adequate for a straightforward listing operation, but it omits some available filters and provides no differentiation from sibling search tools. With no output schema or annotations, a bit more context about defaults or result behavior would make it 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a useful summary of filter dimensions, but it is slightly imprecise: 'accessibility' is not a separate parameter, and darkMode, rtlSupport, and opinionatedLevel are omitted. Overall it does not add significant meaning beyond the schema.
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 names the operation ('List') and the resource ('available UI design systems and component libraries'), and it mentions optional metadata filters. It does not explicitly distinguish itself from the sibling search_ui_systems, but the verb + resource combination is specific enough to understand the core purpose.
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 gives no guidance on when to choose this tool over search_ui_systems, compare_ui_systems, or recommend_ui_systems. It implies a listing/filtering use case, but it never states exclusions, prerequisites, or scenarios where a sibling would be more 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 only describes input semantics and doesn't disclose likely read-only behavior, result ranking/relevance, output shape, or how filters like noveltyPreference affect results. It doesn't contradict annotations, but it under-discloses.
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 focused sentence with the verb and resource front-loaded. The parenthetical examples are numerous but earn their place by clarifying what counts as a valid natural-language query. There is no filler or repetition.
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?
With no output schema and no annotations, the description carries more responsibility. It effectively guides the agent on query phrasing but doesn't describe the return value, ordering, default limits, or how this tool relates to list/get/compare siblings. It is enough for a basic invocation but not fully complete for nuanced tool selection.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the query parameter by explaining that it accepts natural language, keywords, tags, or concepts and giving concrete example queries not present in the schema. Other parameters are adequately covered by their schema descriptions.
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 uses a specific verb and resource: 'Search UI systems', and elaborates the query modes (natural language, keywords, tags, concepts) with concrete examples. It clearly conveys a discovery-oriented purpose, though it does not explicitly differentiate from sibling tools like list_ui_systems.
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 when to use it: when the user wants to find UI systems by concept, style, or description rather than by known identity. However, it doesn't explicitly state when not to use it or mention alternatives such as get_ui_system for a specific system or list_ui_systems for unfiltered enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses a valuable behavioral detail: the response includes mandatory implementation rules and constraints for the AI agent. However, it does not mention behavior when no selection exists, whether it is strictly read-only (implied by 'Get'), or how the optional projectPath affects the result.
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?
A single sentence that front-loads the core purpose ('Get the currently selected UI system') and adds the key additional output without any filler. Every word earns its place.
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?
For a simple getter with one optional parameter, the description adequately states what is returned. However, the absence of an output schema and the large sibling set mean the agent could benefit from knowing the return format or how to distinguish this from get_ui_system. The description is serviceable but leaves some context to inference.
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 the only parameter (projectPath) as 'Optional project root path to inspect'. The description adds no further meaning about how projectPath interacts with the active session/project, so a baseline score of 3 is appropriate.
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 uses a specific verb ('Get') and a clearly defined resource ('currently selected UI system'), and also states the additional output of 'mandatory implementation rules and constraints'. This clearly distinguishes it from sibling tools like get_ui_system or list_ui_systems by highlighting the 'selected' scope.
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 does not provide guidance on when to use this tool versus alternatives such as get_ui_system or list_ui_systems. There is no explicit 'use this when' or 'instead of' statement, leaving the agent to infer the intended use from the 'currently selected' phrase alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The verb "Get" and the described outputs strongly suggest a read-only operation with no side effects, but the description does not explicitly confirm this or mention auth requirements, rate limits, or output structure. It is adequate for a simple read tool but leaves some behavioral traits unspecified.
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, front-loaded sentence that states the action and the complete list of returned content without any filler. Every element earns its place, and the length is proportionate to the tool's simplicity.
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?
For a tool with only two parameters and no output schema, the description is largely sufficient: it enumerates the output categories and the schema fully covers the inputs. The main gap is that the output format and any behavioral constraints (such as authentication) remain implicit, but this is minor given the tool's low complexity.
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 both `id` and `framework` fully documented, so the schema carries the parameter semantics. The description adds general context about installation content but no parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate.
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 names a specific verb ("Get") and a clear resource (installation details for a UI system), then enumerates the exact return types: package names, installation commands, peer dependencies, and setup instructions. This specificity distinguishes it from sibling tools like get_ui_system or get_component_guidance. An agent knows precisely what this tool provides.
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 gives no explicit guidance on when to use this tool versus alternatives such as get_ui_system, search_ui_systems, or get_component_guidance. There are no preconditions, exclusions, or routing cues. Usage is only vaguely implied by the tool's content focus, which is not enough given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context: the output range (3-7), the influence of project type/framework/preferences, and a deliberate bias toward hidden gems. It does not disclose edge cases, return value details, or authorization implications of preferences like 'allow-restricted', but it is not misleading.
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, front-loaded sentence. It names the action, object, result count, and key inputs without filler, and the 'hidden gems' phrase earns its place by conveying the tool's differentiator.
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?
The description is adequate for basic invocation: it implies the required projectType and the optional framework/preferences inputs, and the schema fills in the remaining parameter details. However, with no output schema, it does not describe what fields each recommendation will contain, nor does it explain behavior when no systems match or how noveltyPreference affects the result set.
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 baseline is 3. The description mentions projectType, framework, preferences, and discovery options at a high level but adds no semantic detail beyond what the schema already provides for each parameter.
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 states a specific action and object: 'Recommend 3-7 suitable UI design systems'. It also names the key inputs (project type, framework, developer preferences) and a distinctive discovery focus ('hidden gems rather than defaulting to mainstream choices'), which clearly sets it apart from sibling tools like list_ui_systems and search_ui_systems.
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 when to use the tool: when an agent needs curated recommendations based on project type, framework, and preferences. However, it gives no explicit comparison to sibling tools, no when-not-to-use conditions, and no guidance on when to choose list_ui_systems or search_ui_systems instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose that strict mode locks the selection and prohibits unrequested library substitutions, which is useful. However, it does not mention other behaviors such as overwriting an existing selection, persistence effects, or any restrictions/acknowledgement requirements.
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 sentences with no filler. The first sentence front-loads the core purpose, and the second adds the most important behavioral caveat. Every sentence earns its place.
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?
The schema covers all parameters, but the tool has six parameters, no output schema, and no annotations. The description is adequate for basic selection but leaves gaps around persistence, restricted-license acknowledgement, and what happens to a previously selected system.
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 baseline is 3. The description only maps to strictMode via 'Strict mode' and does not add any meaning beyond the schema for id, persist, framework, projectPath, or acknowledgeUsageRestrictions.
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 uses a specific action verb ('Select') with a clear resource ('UI design system') and scope ('for this project/session'). This clearly distinguishes it from the read/search/compare/recommend sibling tools, and from clear_selected_ui_system.
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 when to use the tool: when the AI coding agent needs a UI design system selected for the current project or session. However, it does not explicitly contrast it with alternatives such as get_selected_ui_system, recommend_ui_systems, or clear_selected_ui_system, leaving usage boundaries to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose the main action and optional file removal. However, it omits side effects such as irreversibility, behavior when no selection exists, and whether the active-selection state is affected when removePersisted is false.
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 sentence with the primary action front-loaded and the optional condition clearly appended. Every clause contributes value, and there is no filler or redundancy.
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?
For a simple tool with two optional parameters and no required fields, the description adequately covers the core behavior and the optional destructive action. Minor gaps include edge-case behavior (e.g., what happens if there is no active selection) and return values, but these are not critical given the schema richness.
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 baseline is 3. The description mostly paraphrases the removePersisted parameter behavior and adds no new semantic detail beyond what the schema already provides for either parameter.
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 uses the specific verb 'Clear' and identifies the resource as the 'currently active UI system selection', which clearly differentiates it from sibling tools like select_ui_system and get_selected_ui_system. It also mentions the optional removal of the .ui-system.json file, adding another layer of specificity.
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 the use case—clearing the active selection—and communicates the condition for the removePersisted option, but it does not explicitly contrast with sibling tools or state when not to use this tool. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is an analytical, non-mutating comparison and reveals the dimensions evaluated: styling, accessibility, density, opinionated level, strengths, weaknesses, and target domains. However, it does not describe the output format, behavior on invalid system IDs, or any data-fetching implications, so transparency is adequate but incomplete.
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 sentence with no filler. The verb, resource, count bounds, and comparison dimensions are all front-loaded, making it immediately scannable for an agent.
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?
For a one-parameter tool, the description is nearly complete: it tells the agent what to pass (2 to 8 UI systems) and what aspects will be compared. Since there is no output schema, it would benefit from a brief note about the result format, but this omission does not prevent correct invocation or tool selection.
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 already fully documents the 'systems' parameter, including min/max items, item type, and an example. The description adds only the '2 to 8' count constraint and the UI-system domain, reinforcing rather than extending the schema. Since schema coverage is 100%, a baseline score of 3 is appropriate.
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 states a specific action ('Compare'), a bounded scope ('2 to 8 UI systems'), and the exact comparison dimensions. This clearly distinguishes the tool from siblings like get_ui_system, list_ui_systems, and search_ui_systems, which operate on single systems or lists rather than side-by-side comparison.
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 the tool should be used when comparing multiple UI systems side-by-side, which helps separate it from single-system tools. However, it does not explicitly mention when not to use it or name alternatives like recommend_ui_systems for cases where a single recommendation is needed. Usage guidance is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. The verb 'Get' and the language about returning metadata clearly imply a read-only lookup with no side effects, but the description does not explicitly state that nothing is modified or selected, nor does it disclose any error behavior or prerequisites beyond having a valid ID.
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 focused sentence that front-loads the key action and resource, then packs the return-content categories efficiently. There is no filler or redundancy.
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?
For a simple one-parameter getter with no output schema, the description adequately covers what input is needed and what kind of metadata will be returned. It could be slightly richer by noting how this relates to get_component_guidance, but it is not incomplete for direct invocation.
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 coverage is 100% and the schema already documents the 'id' parameter with examples. The description adds no new parameter-level details beyond reinforcing that the ID must refer to a specific UI system.
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 states a specific verb ('Get') and resource ('complete detailed metadata... for a specific UI system ID'), and enumerates the returned content categories. It clearly distinguishes this tool from siblings like list_ui_systems and search_ui_systems by emphasizing the specific-ID scope.
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 phrase 'for a specific UI system ID' implies the tool is used when a caller already knows the exact ID and needs full details, which is usable guidance. However, it does not explicitly say when to prefer this over siblings like search_ui_systems, get_component_guidance, or select_ui_system.
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 the behavioral disclosure burden. It clearly indicates a read-only lookup and enumerates the content areas returned, which is meaningful behavioral context; it does not cover failure or edge-case behavior, but none of those are critical for this lookup shape.
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 focused sentence that front-loads the action and enumerates concrete output categories. No filler or repetition is present.
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?
For a two-parameter lookup with no output schema, the description conveys the return categories and the input schema fully documents the required parameters. It doesn't explain handling of invalid IDs or exact response structure, but that is a minor gap for this simple tool.
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?
Input schema already documents both parameters at 100% coverage, so the baseline applies. The description adds component examples and the notion of a specific UI element, but it does not add substantial new meaning beyond the schema.
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 names a specific verb ('Get guidance') and a specific resource ('canonical component names, import statements, props conventions, accessibility notes, and official documentation links') for a UI element, distinguishing it from system-level sibling tools like get_ui_system and list_ui_systems. Examples such as Button, Dialog, and Table further clarify the target.
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 phrase 'for a specific UI element' gives clear context for when to use this tool, and the output categories make it distinct from system-level siblings. It does not explicitly name alternatives or exclusion conditions, so it stops short of full 5 guidance.
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:

[![UI-System-Selector-MCP MCP server](https://glama.ai/mcp/servers/MossaJehad/UI-System-Selector-MCP/badges/card.svg)](https://glama.ai/mcp/servers/MossaJehad/UI-System-Selector-MCP)

Score Badge

Copy to your README.md:

[![UI-System-Selector-MCP MCP server](https://glama.ai/mcp/servers/MossaJehad/UI-System-Selector-MCP/badges/score.svg)](https://glama.ai/mcp/servers/MossaJehad/UI-System-Selector-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/MossaJehad/UI-System-Selector-MCP'

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