MCP server that exposes Google Gemini media generation capabilities (images, videos, audio, music) as MCP tools over stdio transport
Server has 12 tools with basic descriptions and some parameter documentation, but critical gaps prevent higher scores. Tool names follow verb_noun convention (generate_image, edit_image, etc.), which is good. However, input schemas are not visible in the provided source code, only handler signatures show parameter types (provider.ImageRequest, provider.AudioRequest, etc.), making it impossible to verify JSON Schema completeness. Descriptions are present but generic (avg ~100 chars), lacking WHEN to use guidance and dependency hints. No output schemas documented. Error handling returns fmt.Errorf wrapping, which does not guide LLM recovery. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE vs READ_ONLY risk classifications. Async video tools (generate_video, animate_image, extend_video) lack explicit polling guidance in descriptions.
Animate a still image into a video clip. Provide the path to a source image and a prompt guiding the animation. This is an async operation — use video_status to poll progress and download_video to retrieve the result.
Compose a new image using 1-3 reference images and a text prompt for style/content guidance.
Download a completed video generation to a local file. Only call this after video_status reports the operation is complete.
Edit an existing image using a text prompt. Provide the path to the source image and a description of the desired changes.
Extend a previously generated video with a continuation prompt. Requires the operation ID from the original generation. This is an async operation — use video_status to poll progress and download_video to retrieve the result.
Input schemas not visible in source code. Tool handlers reference provider.ImageRequest, provider.AudioRequest, etc., but JSON Schema definitions are not shown. Cannot verify parameter types, descriptions, enums, or constraints.
Output schemas not documented. Tool handlers return mcp.CallToolResult with TextContent, but structured output schemas (what fields the LLM should expect) are not declared. Async video tools return operation IDs but no schema for video_status response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Generate speech audio from a text prompt using Google's Gemini TTS. Supports voice selection and language configuration.
Generate an image from a text prompt using Google's Gemini image models.
Generate music from a text prompt using Google's Lyria models. Supports genre, instruments, BPM, key, mood, structure tags like [Verse] [Chorus] [Bridge], and custom lyrics.
Generate a video from a text prompt using Google's Gemini video models. This is an async operation — use video_status to poll progress and download_video to retrieve the result.
Show current server configuration including active backend and output directory.
List the models supported by this server with their tiers, capabilities, supported resolutions, and pricing guidance.
Check the status of an async video generation operation. Returns progress info (pending, processing, complete, or failed).
Async video operations lack explicit polling guidance. Descriptions mention 'use video_status to poll progress' but do not specify polling interval, timeout, or max retries. LLMs may poll too aggressively or give up prematurely.
No tool annotations despite clear risk classifications. Tools marked WRITE (generate_image, edit_image, generate_video, etc.) should declare destructiveHint=true. READ_ONLY tools (video_status, list_models, get_config) should declare readOnlyHint=true. Annotations guide LLM planning and safety.
Error handling does not guide LLM recovery. Handlers return fmt.Errorf('generate image: %w', err), which produces raw error messages.