moonvy-ui-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct responsibility: URL parsing, listing pages, fetching design metadata, layer indexing, node style extraction, tree traversal, token extraction, full spec generation, asset download, and cache management. No two tools overlap in purpose, making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent 'moonvy_verb_noun' pattern using snake_case (e.g., moonvy_list_pages, moonvy_get_node_style). The prefix uniformly identifies the server, and verbs are action-oriented with descriptive nouns, creating a predictable and readable API surface.
Tool Count5/5
With 10 tools, the server covers the core workflow of navigating Moonvy designs, extracting styles, tokens, specs, and assets without excess. The count is well-scoped for its purpose—neither too sparse nor bloated.
Completeness4/5
The tool surface covers the full design-to-code pipeline: parse URLs, navigate hierarchy, retrieve detailed node styles, extract tokens, generate UI specs, and download assets. A minor gap is the lack of tools for editing or creating designs, but given the read-focused nature of this server, the existing set is comprehensive and leaves no dead ends for typical usage.
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

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 describes what is extracted but does not state whether the operation is read-only, whether it affects state, requires authentication, has rate limits, or any side effects. The description omits even basic behavioral context like caching or scope of extraction.
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 sentence that lists all the extracted token types without filler. It is appropriately concise and front-loads the main purpose. No unnecessary words 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?
While the description lists what is extracted, it does not clarify the scope of extraction (whole design vs. page), the return format, or any prerequisites. Given the absence of an output schema and the richness of the token types, agents might need more detail on how the output is structured. It is minimally adequate but leaves 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?
Schema coverage is 100%, with the single 'url' parameter fully documented. The description does not add any additional meaning about the parameter beyond what the schema provides. Baseline for full schema coverage is 3, and the description does not contribute extra value here.
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 ('Extract') and clearly enumerates the resource and output types: colors, gradients, fonts, text metrics, radii, inferred padding/gaps, and shadows. This distinguishes it from sibling tools like moonvy_list_pages (page listing) or moonvy_get_node_style (node-level styles). The 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.
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 does not mention any conditions, exclusions, or alternatives such as moonvy_get_ui_spec or moonvy_get_design. Agents must infer usage from the name and context, which is insufficient given the broader tool family.
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 bears the full disclosure burden. It usefully reveals a behavioral trait — the output can be large and should be constrained to protect model context — which is valuable. But it stays silent on what includeHidden does, whether hidden layers are traversed, and the shape/size of the returned payload beyond 'styles'. Partial but non-empty disclosure.
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 tight sentences with zero filler. The purpose is front-loaded in the first sentence, and the second sentence delivers actionable usage guidance. Every clause earns its place; nothing is redundant or padded.
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 6-parameter tool with no annotations and no output schema, the description covers purpose, the context-compactness tradeoff, and hints at two parameter groups. It omits when-to-choose-this-tool guidance and includeHidden semantics. Adequate but with clear gaps for a tool of this 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?
Schema coverage is only 33% (only url and frameId have descriptions), so the description must compensate for the four undocumented parameters. It does address maxDepth/maxNodes via 'Limit depth and node count' and withStyle via 'Styles include exact UI values and CSS', but includeHidden is never explained. It partially compensates but leaves a gap.
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 states a specific verb and resource ('Return the nested design layer tree'). The word 'nested' usefully distinguishes it from the flat-filter sibling moonvy_list_layers, and mentioning that styles carry 'exact UI values and CSS' adds concrete scope. It could more explicitly contrast itself with list_layers and get_design, so it's clear but not fully differentiated.
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 instruction to 'Limit depth and node count to keep model context compact' gives real guidance on how to invoke the tool responsibly. However, it gives no explicit when-to-use vs when-not-to-use guidance and never names any sibling alternative, so an agent must infer when to pick get_tree over list_layers, get_design, or get_node_style.
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. It only states the action without disclosing pagination behavior (despite limit/maxApiPages parameters), potential recursion, API call volume, or response format. Agents have no sense of side effects or performance implications for a discovery tool that should be called first.
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, zero fluff. The core action is stated upfront, and the usage hint is concise. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool meant to be called first, essential context is missing: no output schema, no notes on pagination or performance, no explanation of how to interpret results. Without annotations or richer description, an agent cannot anticipate the volume of data or how to proceed after calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (url has a description; limit and maxApiPages do not). The tool description adds nothing about these parameters—no explanation of what limit or maxApiPages control or how they interact. With low coverage, the description should compensate but does not.
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?
States a specific verb ('List') with clear resource ('folders and design files') and scope ('below a Moonvy project or directory URL'). It also differentiates itself from siblings by positioning as the entry point. The instruction 'Call this first when only a project URL is known' reinforces its distinct role.
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?
Explicitly says to call this first when only a project URL is known, giving clear when-to-use guidance. However, it does not delineate when not to use it or point to alternatives for more specific operations, though the sibling names imply that. The guidance is still actionable and helpful.
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 must carry the full burden of behavioral disclosure. The description only states the core action and does not mention side effects (e.g., writing files, overwriting behavior, creation of directories), authentication requirements, error handling, or any constraints on usage. For a tool that writes to the local filesystem, this is a significant transparency gap.
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, concise sentence that front-loads the action and lists the asset types directly. There is no wasted verbiage, and the sentence structure is clear and scannable. It earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having six parameters, no output schema, and no annotations, the description provides only a high-level summary. It does not explain when each asset type should be used, what sliceFormat options do, or any prerequisites or expected outcomes. An agent would need to infer a lot from the schema alone. The description is skeletal and omits crucial operational context.
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 83%, so most parameters already have meaningful descriptions. The description adds a bit of nuance by expanding 'image' to 'image fill' and 'file' to 'top-level file/preview', but it does not clarify the roles of sliceFormat, filename, or the relationship between url and nodeId beyond what the schema provides. Since the schema does the heavy lifting, a 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 clearly states the action (Download) and the resource (design slice, snapshot, image fill, top-level file/preview) plus the destination (absolute local output directory). It distinguishes this tool from siblings like moonvy_get_design or moonvy_list_layers, which are read-only or exploratory. The verb+resource pattern is specific and unambiguous.
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 makes it clear that this tool is for downloading assets, which separates it from sibling tools that parse URLs, list pages, get node styles, etc. However, it does not explicitly state when NOT to use this tool or name alternatives for similar tasks (e.g., when to use moonvy_get_design instead). The context is implied but not formally excluded, so a 4 fits the 'clear context, no exclusions' criterion.
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 states what is returned and gives no indication of side effects, prerequisites, error conditions, or whether it is a read-only operation. As a getter, read-only behavior is implied but never stated; this is a gap given zero annotation support.
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, dense sentence that enumerates the output fields without any fluff. Every word contributes value and the structure is front-loaded with the resource and verb. No unnecessary repetition of the title or schema.
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-param getter with no output schema, the description lists all the return fields, which gives an agent sufficient expectation of the result. However, it omits any caveats (e.g., URL validity, error behavior) and does not mention read-only nature. Given the simplicity, it is nearly complete but missing minor behavioral context.
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 fully documents the single 'url' parameter (100% coverage) with a format and an example pattern. The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate since schema covers it.
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 clear verb ('Return') and a specific resource (design metadata for a Moonvy design URL), and enumerates the exact fields returned (title, genome version, frame IDs, dimensions, child counts). This distinguishes it from sibling tools like list_pages or get_node_style, which target different granularity.
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 you need design-level metadata) but does not explicitly state when not to use it or mention any alternatives. It lacks exclusions or comparisons to siblings like moonvy_parse_url or moonvy_list_pages. The usage context is clear but not formally differentiated.
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 must carry the full burden of behavioral disclosure. It clearly implies a read operation by saying 'Return', which is transparent about its non-destructive nature. However, it does not mention any potential side effects, authentication needs, rate limits, or error behavior. This is adequate but not rich in 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, dense sentence that front-loads the action verb and comprehensively lists the returned data. Every word adds value; there is no fluff or redundancy. This is much like the high-calibration example in efficiency.
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?
The description enumerates all key style properties (fills, typography, borders, etc.) and mentions 'directly usable CSS declarations', giving a solid picture of the return value. However, there is no output schema, and the description does not address error conditions or exact structure of the returned object. Given the tool's complexity, it is largely complete but leaves some details 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%: both 'url' and 'nodeId' are already documented with examples and format. The description adds no further parameter guidance, so the baseline 3 applies. It does not compensate beyond the schema, but it also does not conflict.
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 starts with the verb 'Return' and specifies the resource as 'one node's style', followed by a detailed list of what is returned (size, coordinates, fills, CSS declarations, etc.). This is specific and distinct from sibling tools like moonvy_get_design (whole design) or moonvy_get_ui_spec (UI spec), so an agent can clearly understand what this tool does.
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 does not mention any conditions, prerequisites, or exclusions. An agent is left to infer that this is for retrieving style of a single node, but there is no explicit comparison with siblings like moonvy_get_ui_spec or moonvy_get_design.
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 the output type (flat index) but does not mention critical behaviors such as the default exclusion of hidden layers (though `includeHidden` parameter exists), the `maxNodes` limit and its effects, or whether the list is sorted. It also does not disclose any side effects or limitations. This is a significant gap for a tool with no annotation coverage.
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, no filler. The first sentence succinctly lists what is returned, and the second gives actionable guidance. The key differentiating term 'flat' is front-loaded. 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?
The description covers what the tool returns in terms of data fields, but it omits important operational context such as the default behavior of `includeHidden`, the effect of `maxNodes`, or whether the index is recursive. Since there is no output schema to detail return structure, the description should be more explicit about how results are formatted and bounded. It is adequate but not comprehensive for a tool with no annotations and no output schema.
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 description adds no information about any of the four parameters; it does not explain `url`, `frameId`, `maxNodes`, or `includeHidden`. However, the input schema itself already provides detailed descriptions for each parameter (e.g., url format, maxNodes constraints), so the schema does most of the heavy lifting. Given the moderate schema coverage (50%), the description does not compensate for the gap but also does not contradict or add confusion.
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 action ('Return a flat layer index') and the resource ('Moonvy layers'), and specifies the exact output fields (node IDs, names, types, depth, absolute bounds, parent-relative positions). It distinguishes itself from sibling tools like `moonvy_get_tree` by emphasizing 'flat' rather than hierarchical structure, and from `moonvy_get_node_style` by positioning this as a precursor step.
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 provides a concrete use case: 'Use it to find a node ID before requesting exact style.' This tells the agent when it is appropriate to call this tool. However, it does not explicitly mention alternatives or when NOT to use it (e.g., when a tree structure is needed, use `moonvy_get_tree`). The guidance is specific enough but lacks exclusions or comparison to siblings.
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 adds a useful behavioral fact: 'Does not require authentication.' However, it doesn't disclose behavior on invalid URLs, error handling, or whether any I/O occurs (though parsing is likely local). The description is thin on meaningful behavioral detail beyond the auth note.
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?
One concise sentence that front-loads the action ('Validate a Moonvy URL') and states the return value. No wasted words, efficient and to the point.
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 tool with no output schema, the description sufficiently explains what is returned (the three ID types) and notes that no authentication is needed. It could benefit from a hint that these IDs are used by other tools (e.g., as prerequisites), but the core information an agent needs to call it correctly is present.
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% – the 'url' parameter is fully described with its format ('Moonvy URL, normally /project/:projectId/:dirId/:fileId'). The tool description adds no further parameter detail, so the baseline of 3 applies. The schema already provides the necessary semantics.
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 ('validate') and resource ('Moonvy URL'), and clearly specifies the output: project, directory, and file IDs. This distinguishes it from sibling tools like moonvy_list_pages or moonvy_get_design, which operate on different resources.
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 purpose implies when to use it (when you need IDs from a URL), but there is no explicit guidance on when not to use it or mention of alternatives. It doesn't say, for example, 'use this instead of manually parsing the URL' or reference related tools. 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?
No annotations are provided, so the description carries the full burden. It discloses the action and the trigger, but doesn't elaborate on side effects (e.g., whether it clears only the specific design's cache or all, whether it invalidates cached data for other tools, or if it's immediate). It's not misleading, but it's thinner than ideal for a mutation-like operation.
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 that front-loads the verb and object, with no unnecessary words. Every part contributes to understanding the tool's purpose and usage context.
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?
For a simple no-parameter, no-output tool, the description fully covers what an agent needs to know: what it does and when to call it. There's no missing information that would cause incorrect invocation.
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 zero parameters, and the schema coverage is 100% (empty). Per the rubric baseline for 0 parameters is 4, and the description adds no parameter-related information, which is appropriate since there are none to document.
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 states the specific action ('clear') and resource ('in-memory genome cache'), which is distinct from all sibling tools that fetch or parse design data. It's clear, though the term 'genome' is domain-specific and not further explained. It differentiates implicitly by function.
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 gives a clear trigger condition: 'after a design has changed and must be fetched again.' This tells when to use it, but it doesn't explicitly mention alternatives or when not to use it. Since siblings are all about fetching/parsing, the intent is clear without further exclusions.
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 full burden of behavioral disclosure. It states the output contents (metadata, tokens, component tree) but does not mention side effects, caching, rate limits, or explicit non-destructive behavior. As a read-style tool, this is a moderate gap.
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 zero waste: the first states the purpose, the second focuses on controlling context size. The most important information is front-loaded, and every word earns its place.
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 five parameters and no output schema, the description provides the essential information: what the response contains and how to limit its size. It does not describe includeHidden or potential error cases, but for a straightforward retrieval tool this is largely adequate.
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 coverage is only 40%, so the description must compensate. It adds meaning to maxDepth and maxNodes by framing them as context-size controls, which is not present in the schema. However, it omits any explanation of includeHidden, leaving that parameter semantically vague.
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 ('return') and a clearly defined resource: a UI spec composed of design metadata, inferred design tokens, and a styled component tree. This distinguishes it from siblings that likely return only one aspect, and it is not a tautology of the tool name.
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 'Recommended development tool' signals primary use for development, and the guidance to use frameId/maxDepth/maxNodes to control context size gives practical usage direction. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full differentiation.
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:

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

Score Badge

Copy to your README.md:

[![moonvy-ui-mcp MCP server](https://glama.ai/mcp/servers/Cc-Zzh1/moonvy-ui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Cc-Zzh1/moonvy-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/Cc-Zzh1/moonvy-ui-mcp'

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