Skip to main content
Glama
AriOliv

media-gen-mcp

by AriOliv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

media-gen-mcp

MCP server for AI image & video generation — Google Nano Banana (Gemini image) and Veo 3.1 (video) — routed through a LiteLLM / OpenAI-compatible gateway.

Inspired by hosted media MCPs like Higgsfield's: video generation is asynchronous with polling, and every asset comes back as a public URL (never inline base64), so agents can pass results around cheaply.

Tools

Tool

What it does

generate_image

Text → PNG(s) with nano-banana-pro (Gemini 3 Pro Image, default) or nano-banana-2 (Gemini 3.1 Flash Image — faster/cheaper). Synchronous, returns URLs.

generate_video

Text (± reference image) → async Veo job. veo-3.1 (flagship, native audio, $0.40/s, default) or veo-3.1-lite ($0.05/s for drafts). 4–8s, landscape or portrait. Returns a video_id.

get_video

Poll a job; on completion downloads the MP4 once, caches it, and returns its URL.

list_generations

Browse recent generations (id, kind, model, prompt, URL), newest first.

Related MCP server: Nanana AI Image Generation Server

How it works

agent ──MCP──▶ media-gen-mcp ──OpenAI API──▶ LiteLLM ──▶ Gemini (Nano Banana / Veo)
                    │
                    └── saves PNG/MP4 to MEDIA_DIR, serves at /files/* → URL back to agent

  • Images: POST /v1/images/generations (returns base64; decoded and stored here).

  • Videos: POST /v1/videos → poll GET /v1/videos/{id} → GET /v1/videos/{id}/content.

The LiteLLM deployment must expose the four model aliases (nano-banana-pro, nano-banana-2, veo-3.1, veo-3.1-lite) — see LiteLLM image generation and video passthrough docs for the gemini/ provider mappings.

Quickstart (Docker)

cp .env.example .env   # fill in LITELLM_BASE_URL, LITELLM_API_KEY, MCP_BEARER, PUBLIC_URL
docker compose up -d --build
curl -s localhost:8156/healthz

Endpoints

Path

Auth

Purpose

POST /mcp

Authorization: Bearer $MCP_BEARER

Streamable-HTTP MCP endpoint (stateless — safe for concurrent clients).

GET /files/<name>

none (unguessable names)

Generated assets, immutable-cached.

GET /healthz

none

Liveness probe.

The bearer is mandatory — each generation spends real money, so /mcp must never be exposed unauthenticated.

Environment

Var

Required

Description

LITELLM_BASE_URL

✅

LiteLLM / OpenAI-compatible gateway base URL.

LITELLM_API_KEY

✅

Key for the gateway — prefer a virtual key scoped to the media models with a budget.

MCP_BEARER

✅

Static bearer required on /mcp (≥24 chars; openssl rand -base64 32).

PUBLIC_URL

✅

Public base URL used to build the asset links returned by tools.

MEDIA_DIR

—

Asset storage dir (default /data/media in Docker).

PORT

—

Listen port (default 8000).

Connecting a client

Any MCP client that supports Streamable HTTP + bearer headers:

{
  "mcpServers": {
    "media-gen": {
      "url": "https://your-host/mcp",
      "headers": { "Authorization": "Bearer <MCP_BEARER>" }
    }
  }
}

For local/stdio use (claude mcp add media-gen -- node build/index.js), set the same env vars in .env.

Development

npm install
npm run dev        # HTTP entrypoint with hot reload
npm run typecheck
npm run smoke      # initialize + tools/list against a running server
SMOKE_GENERATE=1 npm run smoke   # also runs one real (paid) image generation

License

MIT

Available Tools

4 tools
generate_imageA

Generate one or more images from a text prompt using Google's Nano Banana models (Gemini image generation). Returns public URLs to the generated PNGs — pass those URLs onward instead of re-downloading the bytes. Synchronous: the call returns when the images are ready (typically a few seconds). Models: 'nano-banana-pro' (Gemini 3 Pro Image — highest quality, default) and 'nano-banana-2' (Gemini 3.1 Flash Image — faster and cheaper, good for drafts and iterations).

ParametersJSON Schema
NameRequiredDescriptionDefault
nNoNumber of images to generate (1-4). Default 1.
modelNoImage model. Default nano-banana-pro.
promptYesWhat to generate. Be specific about subject, style, composition, and lighting for best results.

TDQS

A4.7/5.0
Behavior5/5

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

The description adds significant value beyond annotations (openWorldHint, destructiveHint) by explaining the synchronous behavior, that it returns public URLs (and to pass them onward), and mentions the models used. No contradictions.

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 four sentences with no wasted words. It is front-loaded with the core purpose and models, then covers return format, synchronicity, and model details. Every sentence earns its place.

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 3 parameters, no output schema, and no nested objects, the description is complete. It explains the return format (public URLs), synchronicity, model choices, and how to handle the output. No gaps.

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?

With 100% schema coverage, the description still adds meaning: for 'prompt' it advises specificity on subject/style/composition/lighting; for 'model' it adds context on when to use each variant. The 'n' parameter does not get extra description, but overall adds value.

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 'Generate one or more images from a text prompt' providing a specific verb and resource. It distinguishes from sibling tools like generate_video by explicitly mentioning images and the model names.

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 gives contextual usage guidance by describing the two models with their trade-offs (quality vs. speed) and the synchronous nature. It implicitly differentiates from siblings, but does not explicitly state when not to use this tool.

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

generate_videoA

Start an ASYNCHRONOUS video generation job with Google's Veo models. Returns a video_id immediately — poll it with the get_video tool every ~10s until status is 'completed', which yields the final MP4 URL. Optionally pass image_url to animate a still image (image-to-video). Models and cost: 'veo-3.1' (flagship quality with native audio, $0.40 per second of video, default) and 'veo-3.1-lite' ($0.05 per second — use for drafts and iterations).

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoResolution / orientation: 1280x720 landscape, 720x1280 portrait. Optional.
modelNoVideo model. Default veo-3.1 (use veo-3.1-lite for cheap drafts).
promptYesWhat to generate. Describe subject, motion, camera work (pan/zoom/tracking), and mood.
secondsNoClip duration in seconds. Default 4.
image_urlNoOptional reference image URL (e.g. from generate_image) to animate — image-to-video.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already show non-destructive and open-world. Description adds key behavioral context: asynchronicity, immediate video_id return, polling requirement, and cost per second. No contradictions.

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?

Compact single paragraph of 4 sentences, front-loaded with async nature, then polling, optional image, and model cost. 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?

Covers async job, polling, model selection, optional image, and output format (video_id then MP4). Lacks error/rate limit details but sufficient for typical use.

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 covers 100% of parameters with descriptions. Description adds value with cost implications for model choice, default seconds, and use of image_url for image-to-video. Slightly above 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?

Clear verb 'Start an ASYNCHRONOUS video generation job' with specific resource 'Google's Veo models'. Distinguishes from siblings like get_video (polling) and generate_image (static).

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 tells when to use (async video generation), how to get results (poll with get_video every ~10s), and model selection advice (veo-3.1 for quality, veo-3.1-lite for drafts). Context for sibling tools is clear.

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

get_videoA
Idempotent

Check a video generation job started by generate_video. While the job is running it returns the current status; once completed it downloads the MP4, stores it, and returns its public URL. Safe to call repeatedly — completed videos are cached.

ParametersJSON Schema
NameRequiredDescriptionDefault
video_idYesThe video_id returned by generate_video.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate idempotent and non-destructive hints. The description adds valuable context: while running it returns status, once completed it downloads and caches the MP4 and returns a public URL. This goes beyond what annotations provide.

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, front-loaded with the core purpose. Every sentence adds value with no redundancy.

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?

Despite no output schema, the description explains what the tool returns (status or URL) and mentions caching. With only one parameter and clear annotations, this is fully complete for its 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?

The single parameter video_id has a schema description coverage of 100%. The description adds extra meaning by specifying that the video_id comes from generate_video, helping the agent source the correct value.

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 checks a video generation job started by generate_video and distinguishes itself from siblings like generate_video and list_generations by detailing the behavior of returning status or the final URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool (to check a job from generate_video) and notes it is safe to call repeatedly. It does not explicitly list when not to use it, but the context is clear given the sibling tools.

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

list_generationsA
Idempotent

Browse recently generated media (images and videos) with their public URLs, models, and prompts — newest first.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax entries to return (1-100). Default 20.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate idempotent and non-destructive behavior. The description adds valuable behavioral context: it returns public URLs, models, prompts, and is newest-first, which goes beyond the annotations. It does not mention pagination beyond the limit parameter, but overall it provides sufficient transparency.

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, well-structured sentence that front-loads the core purpose and includes key details. Every word contributes meaning without 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 the tool's simplicity (one optional parameter, no output schema, simple behavior), the description is largely complete. It explains what is returned and in what order. It could mention that it lists all recent generations without filters, but it is sufficient for most use cases.

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%, with the 'limit' parameter fully documented (max 100, default 20). The description does not add additional meaning beyond what the schema provides, so it meets the 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?

The description clearly specifies the action (browse), resource (recently generated media), and details (public URLs, models, prompts) with ordering (newest first). It effectively distinguishes from sibling tools like generate_image, generate_video, and get_video which are for creation or specific retrieval.

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 appropriate usage for browsing recent media, but does not explicitly state when not to use it or provide direct comparison to alternatives. The context from sibling names helps, but explicit guidance would improve clarity.

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.

  1. 4 tool updatesv1.0.0
    • First observedgenerate_image
    • First observedgenerate_video
    • First observedget_video
    • First observedlist_generations
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: image generation (synchronous), video generation (asynchronous start), video polling/retrieval, and history listing. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: generate_image, generate_video, get_video, list_generations. No deviations.

Tool Count4/5

Four tools is slightly on the low end but appropriate for a focused media generation service. Each tool earns its place and covers the core workflows.

Completeness4/5

The set covers image generation, video generation (with polling), and history listing. Minor gaps like a cancel tool for video jobs are not essential for a minimal viable surface.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers