Requires GitHub Personal Access Token for CDN access to Elegant design system assets (CSS, JS, SVG icons, fonts) hosted on GitHub, enabling retrieval of UI components and resources.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Elegant MCP Server create a dashboard page with a top navbar and line chart using Shell B"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Elegant 1.0 UI component library. Provides 14 tools that give AI assistants everything they need to build Log360 Cloud pages — component HTML, page blueprints, shell skeletons, chart snippets, icons, and wiki documentation.
All data is served from the cloud. No local files needed.
Add to .cursor/mcp.json in any project:
{
"mcpServers": {
"elegant-agent": {
"url": "https://elegant-mcp.vercel.app/api/mcp"
}
}
}Reload Cursor. 14 tools will appear.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"elegant-agent": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://elegant-mcp.vercel.app/api/mcp"]
}
}
}Restart Claude Desktop.
Related MCP server: ds-pilot
Just ask the AI to build a page:
"Create Report Servers & Workstation - Windows - Windows Startup report page with all interactions"
The AI will automatically call the MCP tools in order:
setup_project — gets CDN URLs and build rules
get_page_blueprint — gets exact layout specification
get_recipe / get_shell — gets shell skeleton
get_component — gets HTML for each component
Outputs a single index.html with all assets loaded from CDN
Tool | Description |
| CDN URLs, build rules, workflow steps |
| Canonical HTML for any UI component |
| Build recipe for Shell A/B/C/D |
| Complete HTML skeleton with CDN links |
| ElegantEChart HTML+JS code |
| Pre-commit checklist |
| Known issues and fixes |
| All available component names |
| Full-text search across wiki docs |
| 195 SVG icon names with CDN URLs |
| Complete wiki markdown file |
| Complete TopNavBar HTML |
| Detailed page layout specification |
| Search 217 product screenshots |
Returns the full list of known bottlenecks, their root causes, and fixes. Read this when something looks wrong before patching inline.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is read-only ('Returns...') but adds no details about potential side effects, performance, or size. For a simple list retrieval, this is adequate but minimal, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the function, second gives usage guidance. No extraneous words, front-loaded with the primary action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and simple inputs, the description adequately covers what the tool returns (bottlenecks, root causes, fixes) and when to use it (before patching). It lacks details on output format or pagination, but for a diagnostic list tool this is largely sufficient, so a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. Per guidelines, zero parameters baseline is 4. The description adds the meaning of returning a 'full list', which is consistent but does not provide additional syntax or format details beyond the schema's emptiness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'full list of known bottlenecks, their root causes, and fixes'. It uses a specific verb ('returns') and describes the resource comprehensively, distinguishing it from sibling tools like 'get_chart_snippet' or 'get_checklist' which focus on different content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs 'Read this when something looks wrong before patching inline', providing a clear usage scenario. It implies an alternative (patching inline) and gives context for when to use this diagnostic tool, though it does not explicitly name a sibling for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ready-to-use ElegantEChart.* HTML+JS snippet for a chart type.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('returns'), but does not disclose any additional behavioral traits such as whether the snippet is generated dynamically or cached, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It effectively communicates the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one enum parameter and no output schema, the description is fairly complete. However, it could mention what the snippet includes (e.g., HTML+JS) and that it is ready-to-use, which it does. Minor gap: no mention of output format beyond 'snippet'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the single required parameter 'chart_type' is an enum, so the parameter is self-explanatory. The description mentions 'chart type' but does not add detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the resource 'ready-to-use ElegantEChart.* HTML+JS snippet for a chart type', making the purpose specific and distinct from siblings like get_component or get_shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description lacks any mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the pre-commit checklist for a shell type. Run this before declaring a page done.
| Name | Required | Description | Default |
|---|---|---|---|
| shell | Yes |
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 a return but does not indicate whether the tool has side effects, requires authentication, or what happens with different shell values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, no redundant words. It front-loads the main purpose. However, it could be slightly expanded to cover parameter details without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should still clarify the parameter meaning and expected output format. The current text leaves ambiguity about what 'pre-commit checklist' contains and how shell types map.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only vaguely refers to 'shell type' without explaining the parameter's meaning, enum values, or how to use it. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'returns' and clearly identifies the resource as 'pre-commit checklist for a shell type'. It distinguishes itself from sibling tools by focusing on a checklist task, though it could be more precise about what 'shell type' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Run this before declaring a page done.' However, it lacks any guidance on when not to use this tool or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the canonical HTML snippet for an Elegant 1.0 component. Much cheaper than reading a full wiki .md file. Use this instead of Read on any component wiki file.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name. Use list_components to see all options. |
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 the output is an HTML snippet and implies efficiency (cheaper). Although it doesn't explicitly mention read-only or side effects, the purpose is clear and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and contain no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the rich annotations, the description provides sufficient context: purpose, usage guidance, and comparison to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, including one parameter with an enum and description. The tool description adds no extra parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'the canonical HTML snippet for an Elegant 1.0 component,' which is a specific verb and resource. It also contrasts with reading full wiki files, distinguishing it from siblings like get_full_wiki_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: 'Much cheaper than reading a full wiki .md file. Use this instead of Read on any component wiki file.' This provides clear context and excludes alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the COMPLETE content of a wiki .md file. Use only when get_component / get_recipe aren't enough (e.g. reading CSS section for a specific variant). Prefer get_component for HTML snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Wiki filename without path (e.g. 'drawer.md', 'form_input.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It states 'COMPLETE content' but lacks details on potential side effects, auth needs, or performance implications. For a simple read tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and every word adds value with no redundancy or superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one string parameter and no output schema, the description covers all necessary aspects: what it returns, when to use, and input format, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'filename' is described with concrete examples ('drawer.md'), adding meaning beyond the schema's type and requirement. Schema coverage is 100%, and examples enhance usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns COMPLETE content of a wiki .md file, and explicitly distinguishes from siblings like get_component and get_recipe, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use ('Use only when get_component / get_recipe aren't enough') and suggests preferring get_component for HTML snippets, offering clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of available icon SVG filenames. Optionally filter by a search term.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional substring to filter icon names (e.g. 'action', 'ab-', 'rpt') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions basic behavior (returns filenames, optionally filtered) but lacks details on edge cases (e.g., empty result, ordering, pagination, error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and optional filter. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate but could be improved by specifying return format (e.g., array of strings), behavior without filter, and case-sensitivity of the filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'filter'. The description's mention of 'filter by a search term' adds no further meaning beyond the schema's description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of icon SVG filenames with an optional filter. The verb 'Returns' and resource 'list of available icon SVG filenames' are specific. It is distinct from siblings like get_anti_patterns or get_chart_snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives is provided. There is no mention of when to use or not use this tool, nor any reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a detailed visual blueprint of a real Log360 Cloud page — exact layout, component hierarchy, column names, data patterns, chart config, and sidemenu structure. ALWAYS call this before building any page to understand the correct structure.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Page name to get the blueprint for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only describes return contents but fails to disclose that the tool is read-only, non-destructive, or any side effects. Safety profile is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. The imperative usage note is valuable and concise. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists many return details (layout, hierarchy, column names, etc.) but omits the output format (presumably JSON). It adequately covers the tool's purpose for a simple one-param tool, but could be more specific.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described 'page' parameter (enum). The description adds broader context about real Log360 Cloud pages but does not elaborate on the parameter beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns a 'detailed visual blueprint of a real Log360 Cloud page' with exact layout, component hierarchy, etc. It distinguishes from siblings like get_component which returns individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'ALWAYS call this before building any page to understand the correct structure.' Provides clear when-to-use context but lacks mention of when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full recipe for a Shell type (A/B/C/D): required wiki files, CSS load order, scroll model, and shell structure. Read this INSTEAD of LLM-WIKI.md or INDEX.md for page scaffolding.
| Name | Required | Description | Default |
|---|---|---|---|
| shell | Yes | A=Dashboard, B=Settings, C=Reports, D=Split-Panel/Detail |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It indicates a read-only operation by stating 'Returns', but does not disclose any additional behavioral traits like permissions, side effects, or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no extraneous information. Every sentence earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one enumerated parameter, no output schema, no annotations), the description adequately covers the input and output scope. It could optionally mention the recipe's general structure, but it remains complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter, including enum values with descriptions. The tool description reiterates the shell types but adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returns the full recipe for Shell types A/B/C/D, listing specific content like required wiki files, CSS load order, scroll model, and shell structure. It uses specific verbs and resources, and the purpose is distinct from sibling tools like get_shell or get_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool instead of LLM-WIKI.md or INDEX.md for page scaffolding, providing clear usage context. However, it does not differentiate from sibling tools such as get_shell or get_full_wiki_file, missing explicit when-not or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches 217 real Log360 Cloud product screenshots by keywords. Returns matching image URLs you can view to understand exact layout, colors, spacing, and data patterns. ALWAYS use this to see what a page really looks like before building it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords (e.g. 'windows startup', 'alerts main', 'dashboard events', 'settings device'). Searches screenshot filenames. | |
| max_results | No | Max results (default 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. While the search is likely harmless, it doesn't mention any side effects, permissions, or rate limits. The description only states the function without deeper behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence explains the action, and the second provides usage guidance. It is front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description mentions the number of screenshots (217), the product (Log360 Cloud), and the return type (image URLs). Without an output schema, it covers the essentials. It could optionally mention pagination, but it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning both parameters already have descriptions in the schema. The description adds that it searches by filename and returns URLs, but this is only marginal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 217 real screenshots by keywords and returns image URLs. It uses specific verbs like 'searches' and 'returns', and the resource ('Log360 Cloud product screenshots') is well-defined. It distinguishes itself from sibling tools like 'get_icons' or 'get_component' by focusing on visual page layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS use this to see what a page really looks like before building it,' providing strong guidance on when to use. However, it doesn't mention when not to use or provide alternatives, though the implied context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ready-to-fill HTML skeleton for Shell A/B/C/D with all required CSS/JS links and SLOT comments. Copy-paste this as the base, then fill the SLOTs.
| Name | Required | Description | Default |
|---|---|---|---|
| shell | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a ready-to-fill skeleton and is intended for copy-paste, implying it is a read-only template generator with no side effects. However, it does not mention authentication or rate limits, which are likely irrelevant for such a simple tool, so the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, followed by usage guidance. No extraneous words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. It tells what the output is (skeleton with links and slot comments) and how to use it. It does not specify the return format (e.g., plain text) or mention example content, but it is sufficient for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It mentions 'Shell A/B/C/D', connecting the enum values to the concept of shells. It adds context about the skeleton including CSS/JS links and SLOT comments, but does not explain differences between the shells. Still, it adds significant context beyond the bare enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an HTML skeleton for Shell A/B/C/D with CSS/JS links and SLOT comments. The verb 'returns' and resource 'HTML skeleton' are specific, and the sibling tools like get_component are distinct, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage instruction: 'Copy-paste this as the base, then fill the SLOTs.' It does not explicitly say when to use this tool over siblings like get_full_wiki_file, but the focus on shells versus components is implied by naming. No explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available component names you can pass to get_component.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 says 'lists all available component names,' which is adequate for a read-only list operation. However, it does not mention whether the list is sorted, paginated, or has any limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (10 words), front-loaded with the action, and no unnecessary words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It references a sibling tool for context and explains the value of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so no additional parameter info is needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: listing component names. It specifies the output is to be passed to a specific sibling tool (get_component), which distinguishes its purpose from other list/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides the agent to use this tool before get_component. It does not explicitly state exclusions or alternatives, but for a simple listing tool, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all Components-Wiki .md files. Returns file name + matching line + 2 lines of context. Use this to find where a specific class, rule, or pattern is documented.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (case-insensitive) | |
| max_results | No | Max results to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explains the non-destructive search behavior and return format. It does not contradict any annotations (none given) and adds useful behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences provide the essential information: what the tool does and what it returns. No unnecessary words, and the key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with simple parameters and no output schema, the description sufficiently covers the return format and usage context. It addresses the agent's need to understand the tool's role among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by noting the case-insensitive search and the default max_results (implied), and mentions the context lines included in results, which enriches understanding of the query parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across wiki .md files and specifies the return format (file name, matching line, 2 lines of context). This distinguishes it from sibling tools like get_component (returns a specific component) or get_full_wiki_file (returns entire file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to find documentation for specific classes, rules, or patterns. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ CALL THIS FIRST before building any page. Returns mandatory folder structure, copy commands, icon reference table, CSS/JS link patterns, and critical rules (NO CDN, NO inline CSS, NO inline SVG). Skipping this tool will produce broken output.
| Name | Required | Description | Default |
|---|---|---|---|
| feature_name | Yes | Name for the feature folder under figma-export/ (e.g. 'windows-startup', 'dashboard') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains what the tool returns (folder structure, commands, etc.) and its critical role. However, it does not disclose any potential side effects, authentication needs, or rate limits, though such details may be irrelevant for a non-mutating setup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It begins with a clear imperative warning, lists the outputs, and ends with a consequence. Every word adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as a mandatory setup step with multiple outputs, the description adequately covers what the tool returns and its importance. No output schema is provided, but the description lists the outputs clearly. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'feature_name', and the schema description explains its purpose. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns mandatory folder structure, copy commands, icon reference table, CSS/JS link patterns, and critical rules. It emphasizes that it must be called first before building any page, distinguishing it from sibling tools that deal with specific components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first and warns that skipping it leads to broken output. This provides clear usage context, though it does not discuss when not to use it or alternatives, which is acceptable given its mandatory nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: e.g., `get_component` returns HTML snippets, `get_full_wiki_file` returns full wiki content, `get_recipe` provides shell structure, and `get_shell` provides a skeleton. There is no overlap or ambiguity among the tools.
Most tools follow a consistent `get_` prefix pattern (e.g., get_anti_patterns, get_chart_snippet). However, a few tools like `list_components`, `search_wiki`, and `setup_project` deviate, introducing minor inconsistency while still being readable.
With 14 tools, the set is well-scoped for a domain focused on building pages with Elegant components. Each tool addresses a specific need without redundancy, and the count falls comfortably within the optimal 3-15 range.
The tool surface covers the full workflow for building pages: setup, anti-patterns, components, recipes, shells, charts, icons, screenshots, wiki search, and page blueprints. There are no obvious gaps; it provides everything needed to construct a page correctly.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
The Figma MCP server brings Figma design context directly into your AI workflow.
Remote MCP server for creating and selling digital products via MoneMee. It lets AI agents create, publish, and sell digital products such as e-books, AI prompt packs, software, courses without a human touching a dashboard. Docs: https://monemee.com/mcp Sign up on Monemee to get a token.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Anguraj-zoho/elegant-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
