Loading ToolBench
MCP server for accessing Runway ML's generative AI models (text-to-image, image-to-video, text-to-video, avatar videos, and realtime sessions)
The Runway API MCP server exposes 7 tools for AI-driven media generation. While input schemas are present for all tools with enums and parameter descriptions, there are critical gaps in composition, naming, and error handling that significantly limit production readiness. Tools combine multiple concerns (e.g., text_to_image accepts both model selection AND output formatting), descriptions are present but generic, and critical recovery guidance is absent. The server lacks tool annotations (destructiveHint, idempotentHint, readOnlyHint), structured error responses with recovery paths, and does not follow composition best practices. Only get_task is READ_ONLY; the other 6 tools are WRITE operations that modify external state, yet there is no confirmation mechanism, dry-run capability, or clear error recovery guidance.
Generate avatar videos using the gwm1_avatars model with speech synthesis
Retrieve the status and details of a generation task by ID
Generate videos from images using various models (seedance2, seedance2_fast, seedance2_mini, gen4.5, gen4_turbo, veo3.1, veo3.1_fast, veo3, happyhorse_1_0, gemini_omni_flash)
Create realtime interactive sessions with avatars using the gwm1_avatars model
Upscale images using super-resolution models
Generate images from text prompts using various models (gen4_image, gen4_image_turbo, gpt_image_2, gemini_image3_pro, gemini_image3.1_flash, gemini_2.5_flash, seedream5_pro, seedream5_lite)
Generate videos from text prompts using various models (seedance2, seedance2_fast, seedance2_mini, gen4.5, veo3.1, veo3.1_fast, veo3, gemini_omni_flash, and others)
No tool annotations (destructiveHint, idempotentHint, readOnlyHint). Six of seven tools are WRITE operations that mutate external state, but the MCP definitions do not declare this. Agents cannot distinguish safe (idempotent, readonly) from destructive tools without reading descriptions. Current MCP spec (2026-07-28) supports tool annotations in the ToolDefinition schema.
No error recovery guidance in tool descriptions or error responses. Tools that call external generative APIs (image, video generation) can fail for many reasons (content policy violation, rate limit, invalid parameters, service timeout). Current tool descriptions do not explain retry behavior, non-retryable errors, or recovery steps. No evidence of structured error responses with actionable guidance (e.g., 'Content blocked by policy. Try rephrasing the prompt without [forbidden term].').
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Complex nested objects (speech, integration, livekit, contentModeration, tools array) are typed as 'object' with generic descriptions. No internal schema, required fields, or examples are provided. Agents cannot correctly construct these objects without trial-and-error or reverse-engineering from API docs.
Numeric parameters (duration, maxDuration, outputCount, targetSize) lack documented min/max constraints. E.g., maxDuration description says '10-1800' (good), but duration in image_to_video and text_to_video do not specify range. Agents cannot validate or reason about bounds without trial-and-error.
Tool composition violates single-responsibility principle. text_to_image combines prompt-based generation, model selection, ratio control, quality control, background control, seed control, output count, reference image guidance, and output format selection. This should be split: e.g., generate_image + configure_generation_params as separate tools, or accept a structured config object with internal validation. Current design forces agents to reason about all parameters simultaneously.
No confirmation or dry-run mechanism for destructive operations. Generative tasks consume credits/quota and are often expensive. Agents should be able to preview costs, request confirmation, or perform a dry-run before committing. Current tools lack this safety mechanism.
Output schemas are not documented. RunwayTask interface exists in code (with fields id, status, url, error), but tool response schemas are not defined in the MCP tool definitions. Agents cannot plan downstream calls or extract required fields without guessing.
Vague tool names. 'super_resolution' (noun-only), 'avatar_videos' (noun-only), 'realtime_sessions' (noun-only) do not start with action verbs. Names should be verb_noun: 'upscale_image', 'generate_avatar_video', 'create_realtime_session'. Verb-less names reduce agent clarity on what action the tool performs.
Generic parameter descriptions. Many descriptions are minimal or vague (e.g., 'Model ID for text-to-image generation', 'Text description of the image to generate'). Best practice: include expected format, constraints, and examples in description text. E.g., 'Text description of the image to generate (1 - 1000 chars, max 5 sentences; avoid copyrighted names).'
No idempotency guidance. Generative tasks are inherently non-idempotent (each call produces a different output, consumes credits). If an agent retries a failed call, it risks generating duplicate content and wasting credits. Tool descriptions should state: 'Each call generates unique output and consumes quota. Retries will incur additional costs.'