High-performance Model Context Protocol (MCP) server for Google Flow (Nano Banana 2/Pro & Veo 3) featuring Direct CDP WebSocket acceleration, Browser Harness self-healing agent helpers, and multi-reference image injection.
Server has 7 tools with explicit schemas and descriptions. Naming follows verb_noun pattern (flow_generate_image, flow_status, etc.). Descriptions are present and moderately detailed (100-250 chars typical), explaining WHAT the tool does and WHEN to use it. However, several parameters lack descriptions (e.g., flow_manage_project.name has no description), and output schemas are not documented, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance or actionable error messages visible in tool definitions. Security concern: auto_confirm parameter on destructive tools (generate_image, generate_video) defaults to false, which is safe, but no confirmation/dry-run pattern is evident. Composition is reasonable, tools are single-purpose, but flow_connect and flow_disconnect suggest stateful session management, which complicates agent reasoning.
Establishes connection to Google Flow Chrome instance on CDP port (default: 9333).
Closes the browser connection and cleans up MCP state.
Downloads the most recently rendered image or video asset from the active Flow project without re-generating.
Generates high-fidelity images on Google Flow using Nano Banana 2, Nano Banana Pro, or Imagen 4. Supports attaching multiple reference images (e.g. character sheet + background environment) as prompt attachment chips. When auto_confirm=true, submits the prompt and downloads high-res images to output_folder. When auto_confirm=false (default), prepares the prompt and references in the UI for safety review without consuming credits.
Generates cinematic video clips on Google Flow using Veo 3.1 or Omni Flash. When auto_confirm=true, submits generation, monitors rendering progress, and downloads the MP4 file. When auto_confirm=false, prepares prompt without consuming credits.
Output schemas not documented. LLMs cannot predict return structure for any tool. flow_generate_image, flow_generate_video, flow_status, flow_manage_project, flow_download_latest all lack documented return types, forcing LLMs to guess what fields are available for downstream chaining.
Missing parameter descriptions. flow_manage_project.name has no description (required when action='create'). flow_connect.headless lacks context on why headless=false is default. flow_status.full lacks explanation of what 'detailed session metadata' includes.
Stateful session management (flow_connect/flow_disconnect) complicates agent reasoning. Agents must remember to call flow_connect before other tools and flow_disconnect after. No indication of automatic connection or error recovery if connection drops mid-operation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Lists existing Flow projects or creates a new project on the user canvas.
Checks the health and telemetry of Google Flow: Chrome CDP connection state, active user account, session expiration, and real-time remaining credit balance.
No error handling guidance in tool definitions. No indication of retryable vs fatal errors, no recovery suggestions (e.g., 'If generation fails, check flow_status first'). Agents have no actionable path when a tool fails.
Parameter constraints not fully specified. flow_generate_image.output_folder and flow_generate_video.output_folder lack format/validation rules (absolute vs relative path? must exist?). flow_status.full is boolean but no explanation of performance impact or data volume difference.