MasterGo Magic MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MG_MCP_TOKEN | Yes | MasterGo API token for authentication. You can obtain this by: 1) Visit https://mastergo.com 2) Enter personal settings 3) Click the Security Settings tab 4) Find the personal access token 5) Click to generate the token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mcp__getDslA | "Use this tool to retrieve the DSL (Domain Specific Language) data from MasterGo design files and the rules you must follow when generating code. This tool is useful when you need to analyze the structure of a design, understand component hierarchy, or extract design properties. You must provide a fileId and layerId to identify the specific design element. This tool returns the raw DSL data in JSON format that you can then parse and analyze. This tool also returns the rules you must follow when generating code. The DSL data can also be used to transform and generate code for different frameworks." |
| mcp__getComponentLinkA | When the data returned by mcp__getDsl contains a non-empty componentDocumentLinks array, this tool is used to sequentially retrieve URLs from the componentDocumentLinks array and then obtain component documentation data. The returned document data is used for you to generate frontend code based on components. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one retrieves the overall DSL data and code generation rules, the other retrieves component documentation from links found in the DSL. No overlap or ambiguity.
Both tools follow a consistent verb_noun pattern with the 'mcp__' prefix (getDsl, getComponentLink), maintaining naming uniformity.
With only 2 tools, the server feels undersized for a design-to-code workflow. Typically, a design tool MCP would require 3-15 tools to cover essential operations like listing files, managing components, or triggering generation.
The tools cover data retrieval (DSL and component documentation) but lack operations for actually generating code, managing files, or updating designs. Notable gaps exist for a complete code generation pipeline.