media-gen-mcp

Server Quality Checklist

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

Latest release: v0.4.7
Disambiguation5/5
Each tool targets a distinct media type or supporting function (video, card, chart, diagram, formula, icon, image, QR code, polling, model listing, SVG rendering). There is no ambiguity or overlap between tools.
Naming Consistency4/5
Most tools follow a consistent 'generate_<type>' pattern (8 out of 11). The three outliers (get_video, list_models, render_svg) are still descriptive and follow verb_noun pattern, but deviate from the predominant generate prefix.
Tool Count5/5
With 11 tools, the server covers a wide range of media generation tasks without being excessive. Each tool serves a clear purpose, and the count feels well-scoped for the server's stated purpose of media generation.
Completeness4/5
The tool set covers major media types (video, image, chart, diagram, formula, icon, QR code, cards) and includes necessary supporting tools (polling, model listing, SVG rendering). It lacks audio generation or file management, but these are minor gaps relative to the server's focus.
Average 4.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 115 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 for behavioral disclosure. It mentions polling and downloading, implying a read operation with optional file retrieval, but does not disclose potential behaviors like rate limits, authorization needs, or what happens when downloading large 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 two sentences with no superfluous content. It front-loads the action and follows with usage context, which is efficient. However, it could be slightly more structured (e.g., separate parameter notes).
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?
Without an output schema, the description should clarify what the tool returns (e.g., video URL, binary data). It adequately covers the polling/companion use case but omits output details. Given 4 parameters and no schema, more completeness is needed.
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 25% (only 'taskId' has a description). The description adds context for 'videoId' and 'taskId' by stating they are identifiers, but it does not explain the 'download' or 'provider' parameters, leaving critical gaps.
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 action (poll and optionally download) and resource (video task created by create_video). It specifies identifiers (videoId or taskId) and positions itself as a companion to create_video, distinguishing it from sibling tools like generate_image or list_models.
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 explicit usage context: 'use it after an async video returns a handle, or to check/retrieve any video task.' This guides when to use the tool, though it does not explicitly state when not to use it or list alternatives beyond the companion relationship.
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 description discloses that MathJax is bundled, no external dependencies, pure local, and no AI. However, it omits details like return format, potential limitations, or error behavior. With no annotations, these gaps reduce transparency.
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 and front-loaded with the core purpose, followed by examples and technical details. Some secondary info (multilingual triggers) could be omitted, but overall 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?
The tool has 8 parameters and no output schema or annotations. The description explains the main input and rendering behavior but does not mention what the tool returns (e.g., file path, data URI) or how SVG output is handled, leaving the agent to infer.
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 88%, so the baseline is 3. The description adds that even simple formulas qualify and user need not say 'LaTeX', but does not elaborate on other parameters beyond what the schema already provides.
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 ('Render') and resource ('a math formula to vector SVG'), specifies input as LaTeX, and provides multilingual triggers. It is distinct from sibling tools like generate_chart or render_svg by focusing solely on math formula rendering.
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 says 'Prefer this over any manual approach' and notes that MathJax is built-in and local, implying ease of use. However, it does not specify when not to use the tool or compare with alternatives like render_svg.
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 are absent, so description carries full burden. It mentions local download, no rendering libs needed, and that it calls an AI model. However, it lacks details on destructive behavior, authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~100 words) with front-loaded purpose. Includes multilingual triggers which may be extraneous but do not hinder clarity. No redundant sentences.
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 8 parameters and no output schema, the description explains the return value (path) and basic behavior. However, it omits details like cost, rate limits, error responses, and parameter constraints like size formats. Adequate but with 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 63%, and description adds context for 'model' (free models, defaults) and 'images' (image-to-image). But it does not explain 'n', 'size', 'outDir', 'download', or 'provider' beyond what schema already provides. Some added value but not comprehensive.
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 generates or edits AI images via text-to-image or image-to-image. It specifies the resource ('AI image') and actions. Sibling tools like generate_icon or generate_chart are for different output types, so this is well distinguished.
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 use cases ('photographic or illustrated subjects, logo design') and lists multilingual triggers. It implies this is for free models but does not explicitly contrast with alternatives like generate_icon or describe when not to use.
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, so description carries the burden. It discloses smart async behavior (long videos return handle, short block) and mentions free models. It does not cover rate limits or auth needs, but provides useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph, dense with information including multilingual triggers. It is efficient but could be better structured with bullet points for clarity. No waste, but front-loading could be improved.
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 exists. The description mentions a handle for long videos but does not describe the return structure for short videos or error handling. Given the complexity (18 params, no output schema), the description is incomplete.
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 56%, so baseline is 3. The description adds context for `mode` and `wait` parameters but does not explain all 18 parameters. It adds value for key ones but is not comprehensive.
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 creates AI videos in three modes (text-to-video, image-to-video, keyframe animation) and distinguishes it from siblings like `get_video` and `generate_image`. The verb 'Create' and resource 'AI video' are specific.
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 says 'Use this for any 生成视频/做动画 request; no local video tools needed.' It implies use instead of local tools and contrasts with `get_video` for polling. It does not explicitly state when not to use, but the context is clear.
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?
Discloses local rendering, no system installs, no network. With no annotations, description carries transparency burden but omits details on limits, errors, or performance. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured description with front-loaded purpose. All sentences add value. 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?
Adequate for a 8-param tool with no output schema. Explains core functionality, self-contained nature, and multilingual triggers. Could mention output details but is largely complete.
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 75%, so baseline is 3. Description adds minimal parameter info beyond schema; the main text mentions text/URL but doesn't elaborate on colors, margin, etc.
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?
Clearly states verb (Generate), resource (QR code), output formats (SVG/PNG), and source (text/URL). Distinguishes from sibling generate_* tools by specifying QR code specifically.
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?
Highlights pure local rendering with no dependencies, implying use when simplicity and offline capability are needed. Lacks explicit exclusion of alternatives but provides clear context.
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, so description carries full burden. It discloses network requirement, caching, local rendering, SVG/PNG support, and no AI involvement. However, it omits details on error handling or limitations like maximum size.
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 two sentences plus a multilingual line, very concise and front-loaded with the main purpose. Every sentence adds value, no redundancy.
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 6 parameters and no output schema, the description covers purpose, network, caching, format, and browsing reference. It lacks error handling details but is otherwise complete for a fetch-and-render 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 high (83%), so baseline is 3. The description adds examples of icon IDs and mentions multilingual triggers, but does not significantly enhance parameter understanding beyond the schema. The schema already describes each parameter sufficiently.
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 fetches and renders vector icons from Iconify, with specific verb 'Fetch and render' and resource 'vector icon / logo / symbol / favicon'. It distinguishes from sibling tools like generate_image and generate_chart by specifying the icon library scope.
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 mentions network dependency and caching, but does not explicitly compare with sibling tools or state when not to use. It implies usage for icon generation but lacks explicit alternatives or exclusions.
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, description fully covers backend behavior, filter fidelity percentages, auto-selection logic, and non-AI nature. Lacks info on side effects or rate limits, but for a render tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with purposeful front-loading (purpose, backends, use case). A few Chinese phrases add color but do not harm clarity. 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?
Covers all 7 parameters with schema and description. No output schema, but description does not explain return value (likely file path). Otherwise complete for complexity level.
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%, but description adds valuable context: explains backend options, auto-selection triggers, scale relevance only to Chrome, and format behavior. Exceeds baseline.
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 it renders SVG to PNG or SVG, explains dual backend, and distinguishes from siblings by targeting effect-heavy graphics that D2 cannot produce. Verb and resource are specific.
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 tells when to use (for glowing/blur effects beyond D2's capabilities) and mentions 'No AI'. Does not provide explicit when-not-to-use or direct comparison to sibling tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently describes a read-only listing operation with no destructive behavior. Could mention idempotency or rate limits, but not critical for a simple list tool.
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 states core purpose, second provides usage guidance. No wasted words, highly efficient and 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 low complexity (1 optional param, no output schema), description covers what the tool returns (models and video constraints) and when to use it. Could mention that the list is filtered by provider, which is implied. Almost complete.
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 0% and parameter 'provider' has no description in schema. Description adds meaning by stating 'per provider (Agnes / Zhipu)', giving concrete examples. However, it does not specify exact allowed values or format, leaving some ambiguity.
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 'List available AI image/video models and video constraints per provider', specifying the action (list) and resource (models and constraints). It also distinguishes from sibling generation tools like generate_image and create_video by noting it is used to discover model names before calling them.
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 'Use to discover model names... before calling generate_image / create_video', providing clear when-to-use context. Does not explicitly state when not to use, but the purpose is sufficiently clear and functional.
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 description fully discloses behavior: built-in rendering engine, in-process, deterministic, no browser/PIL/SVG. Mentions features like gradient, glow, emoji auto, but does not explicitly state the return value format (though schema implies file output).
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?
Description is comprehensive yet well-structured. Front-loaded main purpose, followed by 'do not' warnings, alternatives, template details, features, limits, and multilingual triggers. Slightly long but every sentence is informative.
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 22 parameters and no output schema, description covers templates, feature interactions, and limitations thoroughly. It doesn't explain return values but the output (file) is inferred from outDir and format parameters. Adequate for the complexity.
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 95% (high), baseline 3, but description adds significant meaning: explains templates and field mappings, gradient/glow interactions, logo accepts URL/data URI/local path, format enum values, etc. This adds value beyond schema 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 it generates share cards, OG images, quote cards, posters, cover images (1200x630 PNG). It distinguishes itself from sibling tool 'generate_image' by explicitly noting 'For illustrated or photographic subjects, use generate_image instead.'
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?
Provides explicit guidance: 'Prefer this for ANY text/card/OG/poster/cover-image request' and 'do NOT write HTML+CSS and screenshot it... do NOT use Pillow/PIL/Python.' Also lists conditions like when to use generate_image and limits (e.g., Japanese kana/Korean need fontPath).
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 bears the burden of behavioral disclosure. It details internal use of Vega-Lite, rendering to SVG, no AI, no system installation, and warns about image marks with external URLs not being embedded—highly transparent.
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 comprehensive yet efficient, front-loading the purpose and key guidance. Could be slightly more structured (e.g., bullet points), but every sentence adds value and there is no fluff.
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 of chart generation (nested spec JSON, multiple mark types, encoding) and no output schema, the description is remarkably complete: covers mark types, encoding channels, aggregation, pie/donut specifics, common mistakes, and multilingual triggers. Sibling context is clear.
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 75%, and tool description adds substantial value beyond the schema: includes Vega-Lite links, mark types, encoding channels, pie/bar examples, common mistakes, and format defaults. Only minor redundancy with schema 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?
Description clearly defines the tool as generating bar/line/pie/area/scatter charts and data visualizations using Vega-Lite. It distinguishes from sibling tools like generate_diagram, generate_image, and render_svg by focusing on data-driven charts with specific mark types.
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 advises preferring this tool over writing Python/matplotlib, provides multilingual triggers, and notes that no external libraries are needed. Lacks explicit when-not-to-use compared to generate_diagram or other siblings, but overall context is clear.
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?
No annotations provided, so description carries full burden. It discloses that D2 and Graphviz are built-in (WASM), limits of D2 (no SVG filters), and that mermaid is unsupported. Also details common mistakes and style constraints.
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?
Description is long but well-structured, front-loading core purpose and key constraints. Each sentence is informative, though some could be consolidated; however, given complexity, thoroughness is justified.
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 high complexity (multiple engines, DSL syntax, constraints) and no output schema, the description is remarkably complete. It covers all parameters, usage patterns, limitations, and error prevention.
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?
Schema description coverage is 100%, but description adds enormous value beyond schema: full D2 syntax, examples, common errors, and detailed parameter usage. This is exceptional.
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 explicitly states the tool generates various diagram types (architecture, flowchart, sequence, etc.) and renders to SVG. It clearly distinguishes from siblings by focusing on structured technical diagrams using D2 or Graphviz DSL.
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?
Provides explicit when-to-use ('Prefer this for structured technical diagrams') and when-not-to-use ('For highly stylized graphics... hand-writing SVG is appropriate'). Also warns against shelling out for d2/dot and clarifies mermaid is unsupported in-process.
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:

[![media-gen-mcp MCP server](https://glama.ai/mcp/servers/wangdong233/media-gen-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wangdong233/media-gen-mcp)

Score Badge

Copy to your README.md:

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

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