MeiGen-AI-Design-MCP

by HUANGcvs

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool has a distinct purpose: workflow management, prompt enhancement, image generation, gallery inspiration, model listing, preferences, gallery search, and reference upload. No two tools overlap significantly.
Naming Consistency5/5
All tool names use lowercase snake_case with a consistent verb_noun pattern (e.g., generate_image, list_models, upload_reference_image). No mixing of conventions.
Tool Count5/5
Eight tools cover the major aspects of an AI design workflow without being excessive. Each tool serves a clear function, and the count feels well-scoped for the domain.
Completeness4/5
The set covers the full cycle from inspiration (search_gallery, get_inspiration) to prompt creation (enhance_prompt) to generation (generate_image) with supporting utilities (list_models, manage_preferences, upload_reference_image, comfyui_workflow). A minor gap is the lack of a tool to view or manage generated image history.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 2.8/5.
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?
Annotations already indicate destructiveHint=true, confirming mutability. The description adds no further behavioral context, such as whether changes are permanent, if confirmation is needed, or what side effects occur. For a tool with delete and modify actions, this is a significant gap.
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 single sentence listing actions, which is concise but lacks structure. It front-loads the resource but does not prioritize key information. While not verbose, it could be more organized (e.g., separating read vs. write actions) without adding length.
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 6 parameters and multiple actions, the description does not explain return values or behavior for each action. No output schema is provided, so the agent has no information on what the tool returns (e.g., list returns a list, view returns a workflow object). This is insufficient for an agent to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely recaps the actions. The parameter descriptions in the schema are sufficient, and the description does not clarify relationships or provide examples beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages ComfyUI workflow templates and lists five specific actions (list, view, import, modify, or delete). This is a specific verb-resource pair that distinguishes it from sibling tools like generate_image or enhance_prompt, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. While the actions are listed, there is no explanation of which action is appropriate in which context or when not to use the tool (e.g., for image generation tasks). This leaves the agent without decision-making cues.
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?
The annotations already indicate destructiveHint=true, so the description's mention of generating images adds minor behavioral insight. It identifies three different providers but lacks details on potential side effects (e.g., cost, latency) or error handling. This is adequate but not comprehensive.
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 (two sentences) and front-loaded with the core purpose. However, the second sentence is a tip that could be better integrated, and the structure lacks clear separation of purpose and usage notes.
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's complexity (9 parameters, three providers, no output schema), the description is lacking. It does not explain the return format, how to handle different providers, or provide complete guidance for using parameters. The tip is helpful but insufficient for full contextual 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?
With 100% schema description coverage, the input schema already documents all parameters. The description offers a tip about using referenceImages from gallery URLs but does not add significant semantic meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose (generate an image using AI) and lists the supported platforms (MeiGen, ComfyUI, OpenAI-compatible APIs), making it easy to understand what the tool does and distinguishing it from sibling tools like get_inspiration and enhance_prompt.
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 helpful tip on using get_inspiration() or enhance_prompt() to obtain prompts and suggests using gallery image URLs as referenceImages, guiding the agent on when to leverage sibling tools. However, it does not explicitly state when not to use this tool or provide alternatives for specific scenarios.
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?
Annotations already indicate readOnlyHint=true. The description adds that the tool returns pricing and capabilities, but no further behavioral traits (e.g., pagination, caching) are disclosed.
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, clear sentence with no waste. It front-loads the key information.
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 list tool with good schema and annotations, the description is mostly adequate. However, it could mention the structure of the return data (e.g., what fields are in each model object) since no output schema is provided.
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 single parameter activeOnly is documented). The main description does not add parameter details, but schema already handles it adequately.
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 lists available AI image generation models with pricing and capabilities, distinguishing it from sibling tools like generate_image or enhance_prompt.
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?
No explicit when or when-not to use is provided, but the tool's purpose (listing models) is clear from context. Sibling tools hint at alternatives, but no direct guidance is given.
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?
Annotations indicate readOnlyHint=false, and description says 'read or update', aligning with mutation capability. However, no details on persistence, error behavior, or side effects beyond what annotations imply.
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: first defines scope, second gives a concrete usage tip. No filler or redundancy, extremely efficient.
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?
No output schema or return format described; missing details on what 'get' returns. For a tool with 8 parameters and 4 actions, more behavioral context (e.g., persistence, error cases) would improve completeness.
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% with descriptions, but the description adds context by listing the fields and suggesting a use case (get at start). This enhances understanding beyond the schema alone.
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?
Description clearly states the tool reads or updates user preferences, listing specific fields like default style, aspect ratio, and model. It distinguishes from sibling tools (e.g., generate_image, search_gallery) which focus on generation or searching, not user settings.
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 recommends calling with action 'get' at conversation start to load preferences, but lacks guidance for other actions (set, add_favorite, remove_favorite) and when not to use this tool. Sibling uniqueness partially compensates.
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?
Annotations already provide readOnlyHint=true. The description adds transparency about cost and access: 'Free, no API key needed.' This supplements the annotations well, though no further behavioral details (e.g., output format) are given.
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 extremely concise (two sentences) and front-loads the core purpose. No superfluous words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the main use case and usage context. However, it does not explain the return value format or error scenarios, which could be considered a minor omission.
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 the schema already describes both parameters. The description only mentions the 'prompt' parameter with an example but does not discuss the 'style' parameter or its enum values, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Transform a simple idea into a professional image generation prompt.' It provides an example and distinguishes from siblings like 'generate_image' by focusing on prompt enhancement rather than image generation.
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 use: 'Use when the user provides a brief description... and needs a detailed, high-quality prompt.' It suggests combining with 'gallery inspiration' but does not explicitly mention alternatives or when not to use, which is a minor gap.
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?
Annotations already declare 'readOnlyHint: true'. The description adds value by stating that results include image URLs and suggesting to render them as markdown images for visual browsing. This provides useful behavioral context beyond the read-only nature.
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, each earning its place. First sentence states the tool's function and key feature (1300+ prompts, previews). Second sentence provides usage guidance and display instruction. No wasted words.
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?
No output schema exists, so the description appropriately explains that results include image URLs and suggests display format. It mentions the size of the gallery (1300+). However, it could further detail the response structure (e.g., fields like prompt text, category) or pagination behavior, but overall it is fairly complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds limited extra value: examples for 'query' (e.g., 'cyberpunk') and noting that leaving it empty browses by category. This is helpful but not essential beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches a curated gallery of AI image prompts, including preview images. It distinguishes from siblings like 'generate_image' by specifying use cases: inspiration, exploring styles, or when user says 'generate an image' without a specific idea.
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 use the tool: when users need inspiration, want to explore styles, or have a vague request. It does not mention when not to use, but the context and sibling names imply alternatives like 'generate_image' for direct creation.
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?
The description adds useful behavioral details beyond the annotations: automatic compression, size limits (max 2MB, max 2048px), and that it returns a public URL. Annotations already indicate destructiveHint=true (mutation), but the description clarifies what the mutation does. No contradictions with annotations.
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 three short sentences with no wasted words. The first sentence immediately conveys the core purpose, and subsequent sentences provide necessary constraints and usage guidance. Ideal conciseness.
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 upload tool with one parameter and no output schema, the description covers purpose, constraints, and return type (public URL). It could be slightly more explicit about the return format, but the information provided is sufficient for an agent to use the tool correctly.
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 has 100% coverage with a thorough description of the filePath parameter, including accepted formats and behavior. The tool description adds no new parameter-level semantics beyond restating the purpose, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'upload', the resource 'local image', and the purpose 'for use as a reference in generate_image'. It distinguishes itself from sibling tools like generate_image by focusing on the upload 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 explicitly states 'Call this when the user wants to use a local file as a reference image.' This provides clear guidance on when to use the tool. However, it does not mention alternative scenarios (e.g., using a URL directly in generate_image) 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is safe. Description adds that it returns full prompt and image URLs and suggests showing images to users, which is helpful context beyond annotations.
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?
Three concise sentences that front-load the main action and provide immediate value with downstream usage tips. No redundant or extraneous content.
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 retrieval tool with one parameter and no output schema, the description fully explains what is returned and how to use it in conjunction with sibling tools. No 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 a clear description for the single parameter imageId. The tool description does not add further detail about the parameter, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full prompt and all image URLs for a gallery entry, distinguishing it from search_gallery (which lists entries) and generate_image (which creates images).
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 direct guidance on using the prompt with generate_image() and image URLs as referenceImages for style transfer, and implies it should be used after selecting an entry from search_gallery. Lacks explicit when-not-to-use, but context is clear.
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:

[![MeiGen-AI-Design-MCP MCP server](https://glama.ai/mcp/servers/HUANGcvs/MeiGen-AI-Design-MCP/badges/card.svg)](https://glama.ai/mcp/servers/HUANGcvs/MeiGen-AI-Design-MCP)

Score Badge

Copy to your README.md:

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

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