What can you do with this server?

The mcp-media-engine server provides AI-powered tools for generating images, videos, and audio, plus job management for async workflows. Image Generation * generate_image — Generate any image from a text prompt using multiple models (DALL-E 3, Stable Diffusion, GPT-Image, etc.) with quality tiers (basic, standard, premium) and options like ControlNet and face swap * generate_article_hero_image — Create hero banners for blog posts, CMS heroes, and newsletter headers * generate_email_header_image — Generate wide-format headers optimized for marketing emails * generate_social_teaser_image — Produce social graphics optimized for LinkedIn, Twitter/X, Instagram, or Substack with auto-selected aspect ratios Video Generation * generate_video — General AI video generation with provider-specific parameters * generate_article_teaser_video — Create short 15–30s teaser videos from article content for YouTube Shorts, TikTok, and Instagram Reels Audio Generation * generate_audio — Text-to-speech synthesis with multiple voices, formats (MP3, FLAC, AAC, Opus), and speed controls * generate_article_narration — Generate podcast-style narration of articles for audio newsletters and accessibility voiceovers Job Management * wait_for_job — Poll until a media job completes (up to 10 minutes), returning the final result * get_job_status — Check the current status and result of any job by ID * list_jobs — List and filter jobs by type, status, date range, with sorting and pagination All generation tools return job IDs for non-blocking operation, and support brand/style customization via tone, aspect ratio, target platform, and reference images.

Which integrations are available for this server?

Generates AI-powered images and videos optimized for Instagram, including social teaser images and article teaser videos with appropriate aspect ratios and styles for sharing on the platform.

How do I use mcp-media-engine?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-media-engine Generate an image of a mountain landscape with a lake." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-media-engine

by Tr1ckyMag1ca1

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mcp-media-engine

MCP server for MediaEngine — AI-powered image, audio, and video generation for Claude, Cursor, and other MCP clients.

Tools

Tool	Description
`generate_image`	Generate images from text prompts — full model catalog (Nano Banana, GPT-Image)
`generate_article_hero_image`	Hero banner for blog posts and articles
`generate_email_header_image`	Header image for marketing emails
`generate_social_teaser_image`	Social media graphics for LinkedIn, Twitter, Instagram
`generate_video`	AI video generation with provider-specific params
`generate_article_teaser_video`	Short teaser videos from article content
`generate_audio`	Text-to-speech synthesis
`generate_article_narration`	Audio narration for articles and blog posts
`wait_for_job`	Poll until a media job completes
`get_job_status`	Check status of a media job
`list_jobs`	List media jobs with filtering and pagination

Related MCP server: multimodal-mcp

Installation

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "mediaengine": {
      "command": "npx",
      "args": ["-y", "mcp-media-engine"],
      "env": {
        "MEDIAENGINE_BASE_URL": "https://your-mediaengine-instance.com",
        "MEDIAENGINE_API_KEY": "your-api-key"
      }
    }
  }
}

Cursor

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "mediaengine": {
      "command": "npx",
      "args": ["-y", "mcp-media-engine"],
      "env": {
        "MEDIAENGINE_BASE_URL": "https://your-mediaengine-instance.com",
        "MEDIAENGINE_API_KEY": "your-api-key"
      }
    }
  }
}

Configuration

Environment Variable	Required	Description
`MEDIAENGINE_BASE_URL`	Yes	Your MediaEngine API base URL
`MEDIAENGINE_API_KEY`	Yes	Your MediaEngine API key
`LOG_LEVEL`	No	Log level (debug, info, warn, error). Default: info

Quality Tiers

Tier	Model	Description
`basic`	Nano Banana	Fast and affordable
`standard`	Nano Banana	Balanced quality (default)
`premium`	GPT-Image	Highest quality — clean text rendering

License

MIT

Available Tools

11 tools

generate_article_hero_imageA

Generate a hero banner image for a blog post, article, or editorial page. Creates an AI-generated visual from the title and summary — ideal for CMS hero banners, newsletter headers, and article thumbnails. Use this when you need to create a featured image, hero graphic, or cover illustration for written content. Supports brand style hints and reference images.

ParametersJSON Schema

Name	Required	Description
`size`	No	Output image dimensions. Defaults to 1024x1024.
`tone`	No	Desired emotional tone (e.g. "professional", "playful", "urgent"). Optional.
`title`	No	Title of the article, email, or post. Used to derive visual style and subject.
`summary`	No	Short summary or body text to guide image composition. If omitted, title alone is used.
`brand_style`	No	Brand aesthetic descriptor (e.g. "minimalist dark", "bold colorful"). Optional.
`aspect_ratio`	No	Explicit aspect ratio override (e.g. "16:9", "1:1", "4:5"). Optional.
`content_type`	No	Type of content this image supports (blog, newsletter, email, social). Defaults to blog.
`target_platform`	No	Platform this image targets, used to pick aspect ratio and style conventions.
`reference_images`	No	Optional reference images with roles (e.g. brand logo, style reference).

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description says 'AI-generated visual' but omits behavioral details like async operation, credit cost, or whether it is read-only. With no annotations, the description should disclose more about the generation process and any side effects.

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 well-structured sentences that front-load the purpose and use cases. No extraneous information.

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?

No output schema is provided, and the description does not mention the result format (e.g., URL, base64, job ID). Given sibling tools like get_job_status and wait_for_job, the tool likely returns an async job reference, but this is not indicated. The description should explain the output to help an agent use the result 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?

Schema description coverage is 100%, so baseline is 3. Description adds context about brand style hints and reference images, but does not elaborate beyond the schema definitions.

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 it generates a hero banner image for blog posts, articles, etc. Lists specific use cases (CMS banners, newsletter headers, thumbnails) and differentiates from siblings like generate_social_teaser_image and generate_email_header_image.

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 it for featured images and cover illustrations. Does not explicitly mention when not to use or alternatives, but the context from sibling tools provides implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_article_narrationA

Generate audio narration of article or blog post content using text-to-speech. Creates podcast-style audio, accessibility voiceovers, and audio newsletters from written text. Pass the article title and body text; the tool selects an appropriate voice and submits an async audio job. Returns a job ID to poll for the finished audio file.

ParametersJSON Schema

Name	Required	Description
`text`	No	Full article body to narrate (max 4096 characters).
`speed`	No	Playback speed multiplier 0.25–4.0 (default: 1.0).
`title`	No	Article title. Prepended to the narration if provided.
`voice`	No	Narration voice (default: nova — warm and clear for long-form).
`format`	No	Output format (default: mp3).

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the async nature, returns a job ID, and automated voice selection, but does not detail error behavior, cost, or length limits beyond schema.

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 succinct sentences cover purpose, use cases, parameters, and workflow. No wasted words; each sentence adds essential 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?

Given no output schema, the description explains the return (job ID) and async behavior. It covers inputs, process, and output, but could briefly mention polling or error handling.

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 the description adds value by providing context for defaults (e.g., 'warm and clear' for nova voice, prepending title, maxLength for text). This enhances understanding beyond raw 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 generates audio narration from article or blog post content, specifying use cases like podcast-style audio, accessibility voiceovers, and audio newsletters. It distinguishes itself from the sibling 'generate_audio' by focusing on article-specific inputs and async job submission.

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 explains when to use the tool (for article narration) but does not explicitly compare to alternatives like 'generate_audio'. It lacks clear guidance on when not to use it or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_article_teaser_videoA

Create a short AI-generated teaser video (15–30s) from an article summary or social post. Produces a shareable video for driving traffic from video-first platforms like YouTube Shorts, TikTok, and Instagram Reels. Pass the article title and summary; the tool builds the generation parameters and submits an async video job. Supports tone and brand_style hints.

ParametersJSON Schema

Name	Required	Description
`tone`	No	Emotional tone for the video (e.g. "cinematic", "punchy", "calm").
`title`	No	Article or post title. Required if summary is omitted.
`summary`	No	Article body or summary to drive scene selection and captions.
`provider`	No	Optional video provider override.
`brand_style`	No	Visual brand style (e.g. "dark minimal", "vibrant editorial").
`aspect_ratio`	No	Explicit aspect ratio (e.g. "16:9", "9:16", "1:1"). Optional.
`content_type`	No	Content category (blog, newsletter, email, social). Defaults to blog.
`target_platform`	No	Destination platform — affects aspect ratio and duration defaults.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions async job submission and produces a shareable video, but does not disclose how to retrieve the result or handle the async nature, which is a behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with clear front-loading: the first sentence states the core action. Every sentence adds value with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, inputs, and async submission. However, it does not mention post-submission steps (e.g., using get_job_status), which would be helpful for an agent. Still largely complete given the schema covers all parameters.

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 baseline is 3. The description adds context for title, summary, tone, and brand_style, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a short AI-generated teaser video (15–30s) from an article summary or social post, distinguishing it from sibling tools like generate_video (more general) and generate_article_hero_image (image-focused).

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 to pass the article title and summary, and mentions tone and brand_style hints, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_audioA

Generate audio from text using text-to-speech (TTS) synthesis. Create voiceovers, narrations, podcast audio, or any spoken audio from text input. Supports multiple voices (alloy, echo, fable, onyx, nova, shimmer), formats (MP3, FLAC, AAC, Opus), and playback speeds. Use the intent-specific generate_article_narration tool for article content.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to synthesize into audio (max 4096 characters).
`speed`	No	Playback speed multiplier, 0.25–4.0 (default: 1.0).
`voice`	No	Voice to use for synthesis (default: nova).
`format`	No	Output audio format (default: mp3).

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral details. It lists supported voices, formats, and speed range, which are key behavioral traits. However, it does not mention cost, latency, or whether the output is a downloadable file or URL, leaving some gaps.

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 the core purpose, second lists supported options and provides a usage alternative. No wasted words, front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers input parameters well, it does not describe the output format (e.g., returns an audio file, URL, or ID) despite no output schema existing. This omission reduces completeness for an AI agent needing to handle the result. Additionally, the character limit is in the schema but not reinforced in the description.

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% and each parameter already has a description. The description merely enumerates the voices and formats already in the schema, adding no new semantic value. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool's purpose: 'Generate audio from text using text-to-speech (TTS) synthesis.' It specifies the action (generate), resource (audio), and method (TTS), making it distinct from sibling tools, especially by explicitly naming generate_article_narration as an alternative.

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?

Description provides explicit guidance on when to use this tool vs. alternatives: 'Use the intent-specific generate_article_narration tool for article content.' This helps the agent decide which tool to invoke based on the type of content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_email_header_imageA

Create an AI-generated header image for marketing emails and newsletters. Optimised for wide-format email banners (typically 600px wide) from subject line and body text. Accepts tone and brand_style hints to stay on-brand. Returns a queued media job whose result URL can be embedded in the email template. Use this to create email graphics, newsletter banners, or promotional header visuals.

ParametersJSON Schema

Name	Required	Description
`size`	No	Output image dimensions. Defaults to 1024x1024.
`tone`	No	Desired emotional tone (e.g. "professional", "playful", "urgent"). Optional.
`title`	No	Title of the article, email, or post. Used to derive visual style and subject.
`summary`	No	Short summary or body text to guide image composition. If omitted, title alone is used.
`brand_style`	No	Brand aesthetic descriptor (e.g. "minimalist dark", "bold colorful"). Optional.
`aspect_ratio`	No	Explicit aspect ratio override (e.g. "16:9", "1:1", "4:5"). Optional.
`content_type`	No	Type of content this image supports (blog, newsletter, email, social). Defaults to blog.
`target_platform`	No	Platform this image targets, used to pick aspect ratio and style conventions.
`reference_images`	No	Optional reference images with roles (e.g. brand logo, style reference).

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns a 'queued media job' whose result URL can be embedded in email templates, which is critical behavioral information beyond the input schema. It does not mention authentication, rate limits, or potential destructive actions, but given no annotations, this level of detail 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?

The description is well-structured, starting with purpose, then optimization, then parameters, and ending with usage. It is concise at 5 sentences with no unnecessary repetition, though it could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the output is a queued job and mentions that the result URL can be embedded, which is essential for integration. It covers tone and brand style hints, and the 9 parameters are all described in the schema. It does not elaborate on job status or error handling, but sibling tools (get_job_status, wait_for_job) cover that gap.

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 baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., mentioning '600px wide' implies default aspect ratio concerns, but not explicitly tied to parameters). The description does not significantly enhance understanding of parameter behavior or dependencies.

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: 'Create an AI-generated header image for marketing emails and newsletters.' It specifies the resource (email header image) and verb (generate), and distinguishes from siblings by mentioning optimization for wide-format email banners (600px wide), contrasting with tools like generate_social_teaser_image or generate_article_hero_image.

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 clear usage context: 'Use this to create email graphics, newsletter banners, or promotional header visuals.' However, it does not explicitly state when not to use this tool or compare it to alternatives, leaving some ambiguity about selection criteria among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_imageA

Generate an image from a text prompt using the MediaEngine model catalog. Use this for any image creation request: illustrations, photos, AI art, logos, icons, graphics, or visuals. Accepts a raw prompt and optional aspect ratio, quality tier, model id, and advanced style parameters. Quality tiers: basic/standard (Nano Banana — fast, inexpensive default), premium (GPT-Image — strongest prompt adherence and clean text rendering). One integration, every model: new models are added to the catalog server-side, so the same wiring keeps working. Style guidance: put the desired look in the prompt itself (e.g. "black and white archival photograph", "flat vector illustration") and bake negatives into the prompt ("no text, no words, no logos"). Use the intent-specific tools (generate_article_hero_image, etc.) when you know the content type.

ParametersJSON Schema

Name	Required	Description
`size`	No	Legacy size hint; prefer aspect_ratio.
`model`	No	Catalog model id (see https://mcpmediaengine.com/models). Overrides quality tier. Default: nano-banana.
`prompt`	Yes	Text description of the image to generate. Include the desired style in the prompt (e.g. "photorealistic", "watercolor", "pencil sketch") and constraints like "no text, no words, no logos".
`quality`	No	Quality tier: basic/standard (Nano Banana — fast default), premium (GPT-Image — text rendering, strict adherence) (default: standard).
`face_swap`	No	Use face swap with reference images (default image model).
`hires_fix`	No	High-resolution fix with super_resolution (default image model).
`scheduler`	No	Advanced: sampler/scheduler algorithm (default image model).
`controlnet`	No	Advanced: structural conditioning mode (default image model).
`film_grain`	No	Add film grain effect (default image model).
`aspect_ratio`	No	Output aspect ratio (default: 1:1).
`face_correct`	No	Apply face correction (default image model).
`style_preset`	No	Optional style preset (default image model).
`color_grading`	No	Optional color grading preset (default image model).
`inpaint_faces`	No	Inpaint faces for better quality (default image model, requires super_resolution).
`mask_image_url`	No	URL of mask image for inpainting (default image model).
`controlnet_txt2img`	No	Use structural conditioning for txt2img (default image model).
`controlnet_conditioning_scale`	No	Conditioning scale 0.0-1.0 (default image model).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description explains model catalog updates, quality tiers, and style guidance. It omits cost/rate limits but adequately discloses behavior for a generation tool.

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 thorough and well-structured, front-loading purpose, then parameters, then usage guidance. Slightly long but no redundancy; every sentence adds value.

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, so description should explain return format (e.g., image URL). It covers usage well but misses output details and error handling. Adequate for 17-param tool with good schema coverage.

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 description adds meaning beyond schema: explains quality tiers, style prompt tips, and clarifies that 'size' is legacy. With 100% schema coverage, it adds useful context.

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 'generate' and resource 'image from a text prompt' using the MediaEngine model catalog. It also distinguishes from sibling tools by mentioning intent-specific tools like generate_article_hero_image.

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 explicitly says 'Use this for any image creation request' and advises to use intent-specific tools when the content type is known, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_social_teaser_imageA

Create a social media teaser image optimised for sharing on LinkedIn, Twitter/X, Instagram, or Substack. Auto-selects the best aspect ratio and generates a visual from article or post content. Accepts title, summary, tone, and brand_style. Use this to create social graphics, shareable images, post visuals, or og:image alternatives. Returns a queued media job.

ParametersJSON Schema

Name	Required	Description
`size`	No	Output image dimensions. Defaults to 1024x1024.
`tone`	No	Desired emotional tone (e.g. "professional", "playful", "urgent"). Optional.
`title`	No	Title of the article, email, or post. Used to derive visual style and subject.
`summary`	No	Short summary or body text to guide image composition. If omitted, title alone is used.
`brand_style`	No	Brand aesthetic descriptor (e.g. "minimalist dark", "bold colorful"). Optional.
`aspect_ratio`	No	Explicit aspect ratio override (e.g. "16:9", "1:1", "4:5"). Optional.
`content_type`	No	Type of content this image supports (blog, newsletter, email, social). Defaults to blog.
`target_platform`	No	Platform this image targets, used to pick aspect ratio and style conventions.
`reference_images`	No	Optional reference images with roles (e.g. brand logo, style reference).

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions auto-selecting aspect ratio and returning a queued media job, which are behavioral. But it does not disclose idempotency, side effects, or permissions. Adequate but not rich.

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 fairly concise with five sentences, front-loaded with purpose and key behaviors. Some repetition (e.g., multiple examples of usage) but no unnecessary detail. Well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters, no output schema, and no annotations, the description covers purpose and return type (queued media job) but lacks details on error handling, prerequisites, or how to process the queued job. Could be more complete given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds marginal context by listing some parameters (title, summary, tone, brand_style) and mentioning auto-selection of aspect ratio, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates social media teaser images for specific platforms, with auto aspect ratio selection. The verb 'create' and resource 'social media teaser image' are explicit, and it distinguishes from sibling tools like generate_article_hero_image.

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?

Description provides clear context for when to use: for social graphics, shareable images, post visuals, or og:image alternatives. However, it lacks explicit exclusions or comparisons to sibling tools like generate_article_hero_image, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_videoA

Generate a video using AI video generation. Use this for any video creation request when the intent-specific video tools do not fit. Accepts provider-specific generation parameters directly.

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	Optional provider name.
`inputParams`	Yes	Provider-specific generation parameters.

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description lacks details on behavioral aspects like idempotency, rate limits, authentication, or what 'provider-specific parameters' entail.

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, front-loaded with main purpose, no wasted words.

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 and nested object parameters; description could be more complete about expected output or parameter structure, given 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?

Schema coverage is 100%; description adds 'accepts provider-specific generation parameters directly', which aligns with inputParams but doesn't significantly enhance understanding 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?

Clearly states it generates videos using AI, and explicitly distinguishes from intent-specific video tools like generate_article_teaser_video.

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 this when intent-specific tools do not fit', providing clear when-to-use and implied alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_job_statusA

Get the status and result of a media job by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes	The media job ID (e.g. "mjob_...").

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are given, so the description must fully disclose behavior. It only states 'get status and result' but does not clarify whether it is read-only, if it returns immediately or blocks, or what the response structure is. This leaves the agent guessing about side effects and output details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words; it is concise and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is minimally adequate to invoke it. However, it lacks details about the return format and behavior (e.g., whether it polls or returns cached status), which would help the agent use it effectively.

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 one parameter 'jobId' described as 'The media job ID...'. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.

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 'Get' and the resource 'status and result of a media job by its ID', making the tool's purpose unambiguous. It distinguishes itself from siblings like 'list_jobs' (multiple jobs) and 'generate_*' (creating jobs).

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 usage is clear: call with a job ID to get its status. However, no explicit exclusions or alternatives are provided; the context of sibling tools implies when to use this vs. 'wait_for_job' or 'list_jobs'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_jobsA

List media jobs with optional filtering, sorting, and cursor-based pagination.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for offset-based pagination (1-indexed).
`sort`	No	Field to sort by (default: createdAt).
`type`	No	Filter by media type.
`limit`	No	Max items to return, 1–100 (default: 20).
`order`	No	Sort direction (default: desc).
`cursor`	No	Opaque cursor returned by a previous list_jobs call for pagination.
`status`	No	Filter by job status.
`pageSize`	No	Items per page for offset-based pagination (default: 20).
`createdAfter`	No	ISO 8601 datetime — return jobs created after this time.
`createdBefore`	No	ISO 8601 datetime — return jobs created before this time.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions filtering, sorting, and pagination but omits details like whether it is a read-only operation, rate limits, or if it includes all jobs (e.g., only active). The basic behaviors are covered, but deeper transparency is lacking.

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?

A single 10-word sentence conveys the entire purpose and key features without unnecessary words. Perfectly concise 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 10 parameters and no output schema, the description effectively summarizes capabilities. However, it does not mention return structure (e.g., list of jobs with pagination metadata), leaving a minor gap in completeness for an agent.

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 parameters are well-documented in schema. The description adds only a high-level summary ('optional filtering, sorting, and cursor-based pagination') without new semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'List', the resource 'media jobs', and key features like filtering, sorting, and pagination. It clearly distinguishes this from sibling tools like get_job_status (single job) and generate_* (creation) by focusing on listing with options.

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 implies usage for retrieving multiple jobs with various filters, contrasting with sibling tools like get_job_status (singular) and wait_for_job (polling). However, it does not explicitly state when not to use or provide alternative tool names, leaving some guidance to the agent's inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wait_for_jobA

Wait for a media generation job to complete — polls until the image, video, or audio is ready or the timeout is reached. Use this to get the final result without manually calling get_job_status in a loop. Returns the completed job on success or an error if the timeout expires.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes	The media job ID to wait for (e.g. "mjob_...").
`timeoutSeconds`	No	Maximum seconds to wait before giving up (default: 300).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It correctly discloses polling, timeout, and return of completed job or error on timeout. However, it does not mention behavior for job failures (e.g., generation error), which could be misleading.

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 clear, front-loaded sentences with no redundant information. 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?

Low complexity (2 params, no output schema) but description explains return values. Still, it lacks details on error types and the structure of the completed job object. Sibling tool context is well addressed.

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 descriptions for both parameters. The tool description does not add meaning beyond the schema (e.g., no format examples for jobId). Baseline 3 applies.

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 'Wait for a media generation job to complete' with specific verb and resource, and explicitly differentiates from 'get_job_status' by avoiding manual polling.

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 this to get the final result without manually calling get_job_status in a loop', providing clear when-to-use and naming the alternative sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev1.0.2Jul 12, 2026

Changedgenerate_image20 fields changed

addedInput schema / properties / aspect_ratio

Added value: +{
+  "description": "Output aspect ratio (default: 1:1).",
+  "enum": [
+    "1:1",
+    "16:9",
+    "9:16",
+    "21:9",
+    "9:21",
+    "3:2",
+    "2:3",
+    "5:4",
+    "4:5",
+    "4:3",
+    "3:4"
+  ],
+  "type": "string"
+}

removedInput schema / properties / astria_style

Removed value: -{
-  "description": "Astria style preset (Astria only).",
-  "enum": [
-    "Cinematic",
-    "Animated",
-    "Digital Art",
-    "Photographic",
-    "Fantasy art",
-    "Neonpunk",
-    "Enhance",
-    "Comic book",
-    "Lowpoly",
-    "Line art"
-  ],
-  "type": "string"
-}

changedInput schema / properties / color_grading / description

Previous value: -"Color grading preset (Astria only)."New value: +"Optional color grading preset (default image model)."

changedInput schema / properties / controlnet / description

Previous value: -"ControlNet model (Astria only)."New value: +"Advanced: structural conditioning mode (default image model)."

changedInput schema / properties / controlnet_conditioning_scale / description

Previous value: -"ControlNet conditioning scale 0.0-1.0 (Astria only)."New value: +"Conditioning scale 0.0-1.0 (default image model)."

changedInput schema / properties / controlnet_txt2img / description

Previous value: -"Use ControlNet for txt2img (Astria only)."New value: +"Use structural conditioning for txt2img (default image model)."

changedInput schema / properties / face_correct / description

Previous value: -"Apply face correction (Astria only)."New value: +"Apply face correction (default image model)."

changedInput schema / properties / face_swap / description

Previous value: -"Use face swap with training images (Astria only)."New value: +"Use face swap with reference images (default image model)."

changedInput schema / properties / film_grain / description

Previous value: -"Add film grain effect (Astria only)."New value: +"Add film grain effect (default image model)."

changedInput schema / properties / hires_fix / description

Previous value: -"Use high-resolution fix with super_resolution (Astria only)."New value: +"High-resolution fix with super_resolution (default image model)."

changedInput schema / properties / inpaint_faces / description

Previous value: -"Inpaint faces for better quality (Astria only, requires super_resolution)."New value: +"Inpaint faces for better quality (default image model, requires super_resolution)."

changedInput schema / properties / mask_image_url / description

Previous value: -"URL of mask image for inpainting (Astria only)."New value: +"URL of mask image for inpainting (default image model)."

changedInput schema / properties / model / description

Previous value: -"Model to use for image generation (default: determined by quality tier)."New value: +"Catalog model id (see https://mcpmediaengine.com/models). Overrides quality tier. Default: nano-banana."

changedInput schema / properties / model / enum

Previous value: -[
-  "astria",
-  "dall-e-3",
-  "stable-diffusion",
-  "chatgpt-image"
-]New value: +[
+  "nano-banana",
+  "gpt-image-2"
+]

changedInput schema / properties / prompt / description

Previous value: -"Text description of the image to generate."New value: +"Text description of the image to generate. Include the desired style in the prompt (e.g. \"photorealistic\", \"watercolor\", \"pencil sketch\") and constraints like \"no text, no words, no logos\"."

changedInput schema / properties / quality / description

Previous value: -"Quality tier: basic (fast/cheap), standard (Nano Banana Gemini 2.5), premium (GPT Image 2.0) (default: standard)."New value: +"Quality tier: basic/standard (Nano Banana — fast default), premium (GPT-Image — text rendering, strict adherence) (default: standard)."

changedInput schema / properties / scheduler / description

Previous value: -"Scheduler algorithm (Astria only)."New value: +"Advanced: sampler/scheduler algorithm (default image model)."

changedInput schema / properties / size / description

Previous value: -"Output image dimensions (default: 1024x1024)."New value: +"Legacy size hint; prefer aspect_ratio."

removedInput schema / properties / style

Removed value: -{
-  "description": "Image style, optional (dall-e-3 only).",
-  "enum": [
-    "natural",
-    "vivid"
-  ],
-  "type": "string"
-}

addedInput schema / properties / style_preset

Added value: +{
+  "description": "Optional style preset (default image model).",
+  "enum": [
+    "Cinematic",
+    "Animated",
+    "Digital Art",
+    "Photographic",
+    "Fantasy art",
+    "Neonpunk",
+    "Enhance",
+    "Comic book",
+    "Lowpoly",
+    "Line art"
+  ],
+  "type": "string"
+}

11 tool updatesv1.0.0Jun 17, 2026
- First observedgenerate_article_hero_image
- First observedgenerate_article_narration
- First observedgenerate_article_teaser_video
- First observedgenerate_audio
- First observedgenerate_email_header_image
- First observedgenerate_image
- First observedgenerate_social_teaser_image
- First observedgenerate_video
- First observedget_job_status
- First observedlist_jobs
- First observedwait_for_job

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Tools are generally distinct with specific intent-based variants (e.g., generate_article_hero_image vs. generate_image). Overlap exists between general and specific generators, but descriptions clearly guide usage, reducing confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (generate_*, get_*, list_*, wait_for_*). No mixing of conventions, making the set predictable.

Tool Count5/5

11 tools cover the core media operations (generate images, audio, video in general and specific forms, plus job management) without being excessive. Scope is well-balanced.

Completeness4/5

The tool set covers generation and job lifecycle (status, listing, waiting). Missing delete/abort jobs is minor. Specific media types (article, email, social) are well-represented, leaving few gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp-veoOAuth
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23
Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

@lweight/xbrush-api-mcp
AI & Machine Learning Multimedia Processing Image & Video Processing
lweight
A
license
A
quality
B
maintenance
MCP server for the XBrush AI media generation API, enabling image, video, audio generation, editing, and more directly from Claude Code via async polling.
Updated 2 months ago (2026-07-15 05:43 UTC)
21
28
MIT
multimodal-mcp
Image & Video Processing Audio Processing AI & Machine Learning
rsmdt
A
license
A
quality
C
maintenance
Multi-provider media generation MCP server that generates images, videos, audio, and transcriptions from text prompts using OpenAI, xAI, Gemini, ElevenLabs, and BFL through a single unified interface.
Updated 6 months ago (2026-03-05 20:02 UTC)
6
74
1
MIT
LemGen AI Design MCP
Image & Video Processing AI & Machine Learning Multimedia Processing
gptimage2prompts
A
license
A
quality
C
maintenance
Open-source MCP server for AI image and video creation, enabling prompt library search, prompt enhancement, and media generation from Claude Code, Cursor, and other MCP hosts.
Updated 2 months ago (2026-07-01 13:34 UTC)
8
MIT
mediamcp
AI & Machine Learning Image & Video Processing
legolev
A
license
A
quality
A
maintenance
mediamcp is an MCP server that connects your AI assistant — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, or anything else that speaks MCP — to cloud media models (Gemini Flash Image, GPT-5 Image, Seedream, Veo, Sora, …) via OpenRouter or any OpenAI-compatible API.
Updated 3 days ago (2026-09-03 19:44 UTC)
6
76
3
MIT

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/Tr1ckyMag1ca1/mcp-media-engine'

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