MasterGo Magic MCP

Official

by mastergo-design

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes, but getDesignSections and getDsl overlap as primary and fallback for design data. Descriptions clarify the relationship, so confusion is minimal. The version tool and workflow tools are distinct.
Naming Consistency4/5
All tools except version_0_2_2 follow the mcp__<action><Object> pattern with consistent camelCase. The version tool breaks the pattern but is a minor outlier.
Tool Count5/5
12 tools is well-scoped for a design-to-code server covering extraction, generation, and linking. Each tool serves a clear role without redundancy.
Completeness5/5
The tool surface covers the full design-to-code pipeline: design section retrieval with supplementary SVG/text tools, DSL fallback, C2D and D2C conversion, component generators for multiple frameworks, and metadata. No obvious gaps for the stated purpose.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 10 of 18 community issues answered or closed in the last 6 months
- 99 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC 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 present, and the description does not disclose behavior beyond stating the version. It fails to mention that this is a read-only operation or how the information is obtained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (a single fragment) but not well-structured. It lacks a full sentence explaining the tool's purpose. It cannot be considered concise as defined; it is underspecified.
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?
Given the simplicity of the tool (no parameters, no output schema), the description should at least indicate that this tool returns the current version. The absence of such context makes it incomplete for an agent to understand its purpose.
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 input schema has no parameters, so schema coverage is 100%. The description does not add meaning beyond the schema, but given zero parameters, no additional parameter information is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'the current version is 0.2.2' which is a statement of fact rather than describing tool functionality. It does not clarify that the tool returns or retrieves version information. The name 'version_0_2_2' could be misinterpreted as a static constant.
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?
No guidance on when to use this tool. Siblings like getMeta and getDsl suggest other ways to obtain metadata, but no exclusions or contextual advice are provided.
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 full burden for behavioral disclosure. It mentions the tool retrieves URLs sequentially and obtains documentation data, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what happens if the URL is invalid. The description is insufficient for a mutation tool with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences, but could be more front-loaded. The first sentence contains multiple clauses that could be simplified. While not verbose, it doesn't achieve the efficiency of top-tier descriptions where 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 with no annotations, no output schema, and a clear purpose in a workflow context, the description is incomplete. It doesn't explain what the returned documentation data looks like, how errors are handled, or important behavioral constraints. The mention of frontend code generation adds context but doesn't compensate for missing operational details.
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 single 'url' parameter. The description adds marginal value by mentioning the URL comes from 'componentDocumentLinks property' and should be 'valid', but doesn't provide additional syntax, format details, or constraints beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve URLs from componentDocumentLinks array and obtain component documentation data. It specifies the verb 'retrieve' and resource 'component documentation data', but doesn't explicitly differentiate from sibling tools like mcp__getComponentGenerator or mcp__getDsl beyond mentioning the source array.
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 provides some context for when to use this tool ('when the data returned by mcp__getDsl contains a non-empty componentDocumentLinks array'), but doesn't specify when NOT to use it or mention alternatives. It implies a sequential workflow but lacks explicit guidance on prerequisites or comparisons with siblings.
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 fully disclose behavior. It states that the tool returns 'rules and results,' but does not clarify if the operation is read-only, whether any state changes occur, or any prerequisites (e.g., authentication). This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief paragraph of three sentences, but contains typos ('fileld', 'layerld') and includes an imperative instruction ('you must follow the rules') that could be integrated more concisely. It is not overly long, but clarity is slightly reduced.
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?
The tool has four parameters (including optional format and sourceLayerId) and no output schema. The description does not mention the optional parameters or explain what 'rules and results' means in terms of output structure. For a tool with moderate complexity, the description lacks completeness.
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 covers all four parameters with descriptions (100% coverage). The description repeats the need for fileId and layerId but adds no new semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool is used when building a complete website or obtaining high-level site configuration, which clearly states its purpose. However, it does not explicitly differentiate this tool from its siblings (e.g., getD2c, getDesignSections), which all retrieve design-related information.
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 provides usage context ('when user intends to build a complete website') and states that fileId and layerId are required. However, it does not mention when not to use this tool or suggest alternatives among sibling tools, leaving some ambiguity.
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 fully convey behavioral traits. It mentions saving files but does not disclose what exactly is created, whether it is destructive, or any side effects. The description is vague about the workflow structure.
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 short, consisting of three sentences. The first sentence is somewhat redundant ('Users need to actively call this tool'), but overall it is efficient.
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?
The description lacks details about the output (no output schema exists), such as the structure of the workflow or file types. With four parameters and no output specification, the description is incomplete for an agent to fully understand the tool's behavior.
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%, so each parameter already has a description in the input schema. The description only adds 'save workflow files' context for rootPath but does not significantly enhance understanding 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 states it provides a component development workflow and requires a rootPath to save files. The verb 'get' is used, making the purpose clear. However, it does not differentiate from sibling tools like getFlutterGenerator or getD2c, which are likely different generators.
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 says 'When Generator is mentioned, please actively call this tool,' giving a clear when-to-use hint. It also emphasizes providing an absolute rootPath. However, no exclusions or alternative tools are mentioned, so guidance is limited.
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 full responsibility. It discloses that the tool downloads images, rewrites references, and generates manifests, implying file system modifications. However, it does not state if these actions are reversible, require permissions, or have side effects like overwriting existing files.
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 paragraph that front-loads the activation instruction and then lists functionalities. It is reasonably concise with no redundancy, though it could be improved by using bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and moderate complexity, the description covers the workflow but lacks details on expected return values, error handling, or what happens when parameters are invalid. It is adequate but not fully comprehensive.
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 each parameter already has a description. The tool description adds no additional semantic detail beyond what's in the schema, except reinforcing the requirement for rootPath. Per guidelines, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the Flutter component development workflow. It lists specific deliverables (DSL mapping, asset download, etc.), establishing a distinct purpose. However, it does not explicitly differentiate from sibling tools like mcp__getComponentGenerator, which could be confused. The purpose is clear but lacks sibling distinction.
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 explicitly states when to call the tool: 'When Flutter Generator or Flutter Component is mentioned, please actively call this tool.' It also notes the requirement for an absolute rootPath. However, it does not provide alternative tools or when not to use it.
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. It discloses that the tool reads a file and sends it to the backend, and includes parameter constraints. However, it does not mention destructive behavior, idempotency, permissions, rate limits, or error conditions. The transparency is moderate but not exhaustive.
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 well-structured with separate sections for parameter details and a note. It is concise overall, though there is minor redundancy (the tool's purpose is stated both at the beginning and implicitly at the end). A slightly more streamlined version would improve efficiency, but it remains clear and scannable.
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?
Given the tool has 4 parameters and no output schema, the description thoroughly covers input semantics but omits any mention of return values, error handling, or what happens after the file is processed. This is a significant gap for an agent to use the tool correctly, as it has no information about expected responses or failure modes.
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 input schema provides 100% coverage with descriptions for all parameters. The description adds significant value beyond the schema by explaining the relationship between fileId, shortLink, and layerId, including examples and explicit restrictions (e.g., 'pageid/page_id will not be treated as layerId'). This enriches the agent's understanding of parameter usage.
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 tool's purpose: 'send code files to MasterGo MCP service for C2D processing, synchronizing user code to the design draft.' It uses a specific verb (send/sync) and resource (code to design), and it distinguishes itself from sibling tools like extractSvg and getComponentGenerator by being the only code-to-design tool.
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 provides detailed parameter usage guidelines (e.g., when to provide fileId vs shortLink, restrictions on layerId) but lacks explicit guidance on when to use this tool versus alternative tools. No sibling comparisons or when-not-to-use conditions are mentioned, leaving usage decisions implicit.
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, the description fully carries the behavioral disclosure burden. It details side effects (writing files to disk, avoiding large resources in context), which is commendable. However, it does not mention error handling, permission requirements, or reversibility, preventing a perfect score.
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 concise, front-loads the purpose, and uses a numbered list for clarity. Every sentence adds value, though some redundancy exists (e.g., restating resourcePath in step 2). Still, it is well-structured for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description adequately covers inputs, outputs (a summary), and side effects. It addresses potential context overflow by omitting large resources. For a tool of moderate complexity, this is sufficient but not exhaustive (e.g., no mention of return format or error states).
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 100% (baseline 3), but the description adds significant context: it explains the role of contentId and documentId with examples, and clarifies outDir as optional. This goes beyond mere schema replication, adding practical meaning for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches D2C data from MasterGo and persists it locally, including writing code to HTML and saving SVG/image resources. It well specifies the action and resource, but does not explicitly differentiate from sibling tools like mcp__C2d or mcp__extractSvg.
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 lists steps but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. Usage is implied by the context of D2C data retrieval, but lack of explicit guidance hurts score.
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?
Since there are no annotations, the description bears full responsibility. It states the tool retrieves cached data, implying a read-only operation with no destructive side effects. It also describes the caching behavior and the mapping from path IDs to SVG strings. No contradictory or missing critical traits.
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 relatively concise with a few focused sentences. The most important information (prerequisite, purpose, and usage) is front-loaded. No unnecessary words or repetition, though it could be slightly shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently covers the return format (map of ids to SVG strings) and how to integrate into HTML. It also mentions caching. Missing some error conditions (e.g., if sections not fetched) but overall adequate for the 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?
With 100% schema description coverage, the baseline is 3. The description reiterates the two invocation methods (fileId+layerId vs shortLink) already present in the schema, and does not add new insights or constraints beyond what the schema provides.
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 explains that the tool retrieves cached SVG HTML strings after fetching design sections. It mentions the prerequisite tool (mcp__getDesignSections) and how to use the output (look up id in svgs map, insert svgHtml). However, it does not explicitly differentiate from sibling tools like mcp__extractSvg, which might also deal with SVGs.
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?
Provides explicit usage sequence: call after mcp__getDesignSections. Also offers two input alternatives (fileId+layerId or shortLink) and explains how to use the returned data. Lacks when-not-to-use or alternative comparisons, but the guidance is clear and actionable.
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 fully discloses the internal process: retrieving DSL, finding PATH nodes, resolving color references, and generating SVG markup. It also describes the return format ({ count, svgs }). However, it does not mention potential side effects or permission requirements, which would elevate transparency further.
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 concise and well-structured, starting with a clear purpose statement. Each sentence adds essential information about the tool's functionality, input methods, and output. There is no redundancy or irrelevant detail, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, conditionally required inputs) and the absence of an output schema, the description adequately captures both input options and the return structure. It covers the core behavior and output format but omits details like error handling or limitations, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter's purpose is already documented. The description adds high-level context about the workflow and output but does not enhance understanding of individual parameters beyond their schema descriptions. Thus, it delivers marginal added value, meeting the baseline for full schema coverage.
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 verb and resource: 'Extract SVG data from MasterGo design files.' It provides specific details about the process (retrieving DSL, finding PATH nodes, resolving color references, generating SVG markup) and distinguishes the tool's output format. This differentiates it from sibling tools like mcp__getDesignSvgs by focusing on SVG extraction specifically.
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 offers two input methods (fileId+layerId or shortLink) and notes conditionality, but it does not explicitly state when to use this tool over alternatives such as mcp__getDesignSvgs. The guidance is implied but lacks direct comparisons or exclusion criteria, leaving the agent without clear boundary conditions.
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 full burden. It explains the key format and that text must be used exactly, but does not mention error handling, rate limits, or consequences of missing keys. Basic behavioral context is present but could be more thorough.
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 well-structured: first paragraph explains context and key mapping, then a bullet list of parameter options. Every sentence is necessary and no fluff. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (text retrieval from a design system), the description covers the workflow, key mapping, and parameter options adequately. It lacks an output schema but describes the return value as original text. Some edge cases (e.g., missing keys) are not addressed, but the core functionality is well explained.
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 100%, so the bar is higher. The description adds value by explaining when to use each parameter (e.g., shortLink alternative, sourceLayerId override) and the format parameter's use cases. It goes beyond the schema's basic descriptions.
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 tool retrieves exact text content for large text nodes after fetching sections, explaining the key mapping and that original text is returned. It distinguishes itself from sibling tools by specifying its role in the workflow (after getDesignSections).
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 explicitly tells the agent to call this tool after getDesignSections, provides two calling methods (fileId/layerId or shortLink), and warns against inventing text. It doesn't mention when not to use it relative to siblings, but the workflow guidance is clear.
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?
No annotations provided, but the description warns that the response may be large and exceed context limits, discloses it returns raw DSL data and rules for code generation, and explains the format parameter behavior. Auth or rate limits are not mentioned, but the key behavioral trait of size is covered.
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 well-structured with clear sections and front-loading of purpose and fallback role. It is slightly verbose but each sentence adds value. Could be more concise, but overall it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers all necessary aspects: purpose, usage guidelines, parameter explanation, output characteristics, and behavioral warnings. It is fully sufficient for an agent to select and invoke the tool correctly.
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 100%, so baseline is 3. The description adds context beyond the schema by explaining the fallback scenario, clarifying how shortLink relates to fileId/layerId, and describing the outcome of each format option. This extra guidance justifies a score of 4.
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 tool returns the full DSL in one response, functions as a fallback for mcp__getDesignSections, and distinguishes itself by warning of large output. Purpose 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use only when mcp__getDesignSections is unavailable or returns an error' and 'Prefer mcp__getDesignSections as the primary tool,' providing clear when-to-use and when-not-to-use guidance. Also explains two ways to provide input (fileId+layerId or shortLink).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses behavior such as two modes, stripping svgHtml from PATH nodes, batching requirements, timeout risks, and error handling. No contradictions or omissions are present.
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 well-structured with clear section headers, bullet points, and examples. It is verbose but every sentence adds value. Minor redundancy (e.g., repeated emphasis on batching) could be trimmed, but overall efficient for the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, multi-step workflow, no output schema), the description covers all necessary context: input modes, workflow, batching, fallback, and format options. It leaves no ambiguity about how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning beyond the schema. It explains the effect of omitting/providing sectionIndex, the meaning of each format option (json, yaml, tree), and provides usage examples. This greatly aids an agent in using parameters correctly.
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 it is the main tool for designs and distinguishes two modes (layout overview vs section DSL). It differentiates from siblings by explicitly mentioning fallback to mcp__getDsl and directing to mcp__getDesignSvgs for SVGs, avoiding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, step-by-step usage guidelines: first call without sectionIndex, then fetch all sections in batches of 3-5, and not to call mcp__getDsl after. It also specifies when to fall back to mcp__getDsl on error, giving clear context for when to use this tool versus alternatives.
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:

[![mastergo-magic-mcp MCP server](https://glama.ai/mcp/servers/mastergo-design/mastergo-magic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mastergo-design/mastergo-magic-mcp)

Score Badge

Copy to your README.md:

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

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