This server lets an AI assistant drive Google Flow through your own Chrome session — generating Veo videos and Nano Banana images, downloading them, and stitching long seamless takes with Scene Builder, all with dry runs and crash-safe resume.
Session & UI: flow_connect attaches to Chrome and checks login; flow_status reports connection/project/scene/in-flight jobs; flow_screenshot captures the tab; flow_inspect snapshots/diffs the live UI, searches text, finds media tiles, and watches network requests.
Project & media: flow_project_open opens a Flow project and lists its media ids; flow_media_download downloads any video/image by media id through the authenticated browser session.
Video generation: flow_generate_video creates clips with Veo 3.1 Lite/Fast/Quality or Omni Flash, 4–10 s, 9:16 or 16:9, with optional keyframe/reference images, dry-run (auto_confirm: false), and resume: true to recover in-flight jobs.
Image generation: flow_generate_image creates Nano Banana Pro / 2 / 2 Lite images, 1–4 at a time, in common aspect ratios, with references and the same dry-run/resume safety.
Scene Builder: flow_scene_add turns a clip into a scene; flow_scene_status reads its timeline; flow_scene_extend adds 7-second continuous-motion/audio hops (Veo 3.1 Lite) idempotently, and downloaded clips can be concatenated locally with ffmpeg.
Safe by design: credit-spending tools prepare without sending unless you confirm, retries return existing outputs instead of double-billing, job files survive crashes, and every result is structured { ok, code, message, details }; doctor helps with Chrome/Login/hung-tab troubleshooting.
Provides tools for driving Google Flow, enabling AI agents to generate videos with Veo, generate images with Nano Banana, manage media, and extend clips using Scene Builder.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@google-flow-mcp generate a 9:16 video of a dog running on the beach"
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.
English | 한국어
Let your AI assistant make videos in Google Flow (Veo, Nano Banana) — and stitch them into long, seamless takes with Scene Builder — in plain language:
"Generate an 8-second vertical clip from this keyframe: a rooster crowing on a stone wall at dawn."
"Add it to a scene and extend it twice — keep the slow push-in going, then let the camera rise into the sky."
"Make three 9:16 poster images of a copper weathervane with Nano Banana."
"Show me what the Flow page looks like right now." (
flow_inspect/flow_screenshot)
This is a Model Context Protocol (MCP) server that drives Google Flow through your own Chrome session. It works with Claude Code, Claude Desktop, Cursor, VS Code, Gemini CLI — any MCP client — and with plain JSON-RPC scripts.
❌ Without | ✅ With google-flow-mcp |
Flow has no public API; every clip is a manual click session | Your agent calls |
Veo clips are capped at 8 seconds |
|
One wrong click spends credits | Every generating tool has a dry run ( |
A crash mid-render loses track of the job | Job records on disk let |
UI changes break scrapers silently |
|
Related MCP server: byob
flowchart LR
C["🤖 MCP client<br/>Claude Code · Claude Desktop · Cursor · VS Code · Gemini CLI<br/>or any JSON-RPC script"]
subgraph S["google-flow-mcp — runs on your machine"]
direction TB
T["11 tools<br/>session · generate · media · scene builder"]
F["Flow automation<br/>agent composer · scene timeline · media ids"]
J["Job records<br/>~/.google-flow-mcp/jobs"]
end
subgraph B["Google Chrome (your profile, port 9333)"]
P["one tab owned by this server"]
end
G["☁️ Google Flow<br/>labs.google · Veo 3.1 · Omni · Nano Banana"]
C <-->|"MCP over stdio"| T
T --> F
F <-->|"Playwright over CDP"| P
P <-->|"HTTPS, your login"| G
F -.-> JChrome is launched outside Playwright (so Google's sign-in accepts it) with a dedicated profile that keeps your login. The server never sees a password; prompts go to Flow exactly as you wrote them; downloads come back through the browser's own authenticated session.
🎥 Video generation through the Flow agent composer — Veo 3.1 Lite / Fast / Quality and Omni Flash, 4–10 s, 9:16 or 16:9, with a keyframe as first frame
🖼️ Image generation with Nano Banana Pro / 2 / 2 Lite, any Flow aspect ratio, reference images
🧩 Scene Builder: create a scene from a clip, read its timeline, extend the last clip by 7-second hops that continue motion and ambient audio
🧪 Dry runs for every credit-spending tool, and idempotent retries — asking for the same extension twice returns the file, not a second bill
💾 Crash-safe: long renders are tracked in job files; resume: true finishes them after a restart or timeout
🔍 UI inspection (flow_inspect): snapshot/diff of the live page, text search, media tile positions, network watch
🧾 Structured results: { ok, code, message, details } — clients branch on error codes, never on message text
🩺 doctor checks Chrome, the port, your login and finds hung tabs that would block connections
🇰🇷 🇺🇸 Korean and English Flow UI labels out of the box (add yours in one file)
What | Why |
Node.js 20+ | runs the server ( |
Google Chrome | the automation target; macOS path is the default, others via config |
A Google account with Flow access + credits | generations cost Flow credits exactly like clicking Generate yourself |
claude mcp add google-flow -- npx -y @park-sang-gwon/google-flow-mcpclaude_desktop_config.json → mcpServers:
{
"mcpServers": {
"google-flow": { "command": "npx", "args": ["-y", "@park-sang-gwon/google-flow-mcp"] }
}
}~/.cursor/mcp.json (or project .cursor/mcp.json):
{
"mcpServers": {
"google-flow": { "command": "npx", "args": ["-y", "@park-sang-gwon/google-flow-mcp"] }
}
}.vscode/mcp.json:
{
"servers": {
"google-flow": { "type": "stdio", "command": "npx", "args": ["-y", "@park-sang-gwon/google-flow-mcp"] }
}
}~/.gemini/settings.json:
{
"mcpServers": {
"google-flow": { "command": "npx", "args": ["-y", "@park-sang-gwon/google-flow-mcp"] }
}
}git clone https://github.com/ParkSangGwon/google-flow-mcp && cd google-flow-mcp
npm install && npm run build
claude mcp add google-flow -- node "$PWD/dist/cli.js"npx -y @park-sang-gwon/google-flow-mcp doctorThe first run launches a dedicated Chrome (~/.google-flow-chrome). Sign in to Google in that window — once. doctor then reports flow: logged in. From now on the server reuses that profile; there is nothing to configure unless Chrome is somewhere unusual (see Configuration).
Ask your assistant to open a Flow project and prepare a video without spending credits:
"Call
flow_project_openon https://labs.google/fx/tools/flow/project/… thenflow_generate_videowithauto_confirm: falsefor an 8-second 9:16 clip of …"
You get status: "ready_for_confirmation" and a screenshot path. Say "go ahead" and the agent repeats the call with auto_confirm: true.
sequenceDiagram
autonumber
participant A as 🤖 Agent
participant S as google-flow-mcp
participant B as Chrome tab
participant F as ☁️ Google Flow
A->>S: flow_generate_video {prompt, model, reference_images, auto_confirm}
S->>B: open project · new agent session · settings (ratio, count, model, "confirm: never")
S->>B: attach keyframe → verify thumbnail (else REFERENCE_NOT_ATTACHED, nothing sent)
S->>B: fill instruction
alt auto_confirm = false
S-->>A: status: ready_for_confirmation + screenshot (0 credits)
else auto_confirm = true
S->>S: write job record (baseline of media ids)
S->>B: send (Enter) → handle approval card / policy refusal
B->>F: generate
loop every 6 s, up to 30 min
S->>B: new media ids?
end
F-->>B: clip ready
S->>B: authenticated GET media.getMediaUrlRedirect
S-->>A: status: completed, files[], media_ids[], job_id
endIf the server dies or times out during the loop, call the same tool again with resume: true — it reloads the job, skips the composer and only waits/downloads.
Flow's Scene Builder extends a clip by analysing its last frames and generating what happens next, keeping motion and ambient sound. This server automates the whole path:
flowchart LR
K["🖼️ keyframe"] --> V["flow_generate_video<br/>Veo 3.1 Fast · 8 s · 10 credits"]
V --> A["flow_scene_add<br/>tile ⋮ → Add to Scene → Create scene<br/>0 credits"]
A --> E1["flow_scene_extend #0<br/>Veo 3.1 Lite · +7 s · 5 credits"]
E1 --> E2["flow_scene_extend #1<br/>+7 s · 5 credits"]
E2 --> N["…"]
V -.->|"seed.mp4"| X["ffmpeg concat<br/>(local, free)"]
E1 -.->|"hop1.mp4"| X
E2 -.->|"hop2.mp4"| X
X --> O["🎬 22 s take, one continuous motion"]What we measured on the live UI (September 2026, details in docs/scene-builder.md):
Fact | Value |
Extension length | 7.0 s per hop, separate MP4 with audio (720×1280 for a 9:16 seed) |
Seam | first frame of the hop == last frame of the previous clip (NCC 0.995–0.998), no overlap |
Model | fixed to Veo 3.1 - Lite by Flow (5 credits per hop on Ultra) |
Approval card | none |
Retry / crash |
|
Restate the subject, wardrobe, light and camera move in every hop prompt — Flow does not carry the previous prompt over.
Recipe:
seed = flow_generate_video { model: "veo-3.1-fast", duration: 8, reference_images: ["/abs/keyframe.jpg"], ... auto_confirm: true }
scene = flow_scene_add { project_url, media_id: seed.media_ids[0] }
hop1 = flow_scene_extend { scene_url: scene.scene_url, prompt: "…continues…", after_clip_index: 0, output_dir, auto_confirm: true }
hop2 = flow_scene_extend { ..., after_clip_index: 1, ... }
ffmpeg -i seed.mp4 -i hop1.mp4 -i hop2.mp4 -filter_complex "[0:v][0:a][1:v][1:a][2:v][2:a]concat=n=3:v=1:a=1" take.mp4Group | Tool | What it does | Credits |
🔌 Session |
| Attach to / launch Chrome, open Flow, report | – |
| Connection, login, current project/scene, running tool, in-flight jobs | – | |
| PNG of the owned tab | – | |
| Snapshot → action → diff of the UI; text search, media tiles, network | – | |
| Open a project, list its media ids | – | |
🎥 Generate |
| Veo 3.1 Lite/Fast/Quality, Omni Flash; keyframe; dry run; resume | ✅ |
| Nano Banana Pro / 2 / 2 Lite; 1–4 images; references; dry run; resume | ✅ | |
💾 Media |
| Download any media id through the logged-in session | – |
🧩 Scene Builder |
| Create a scene from a clip → | – |
| Clips, durations, media ids of a scene | – | |
| Extend the last clip by 7 s (Veo 3.1 Lite); idempotent; resume | ✅ |
Full input/output schemas: docs/tools.md (generated from the code, always in sync).
Every tool answers with one JSON text block:
// success
{ "ok": true, "status": "completed", "files": ["/abs/out/flow_ab12cd34_job.mp4"], "media_ids": ["ab12cd34-…"], "job_id": "mtk0…" }
// failure (isError: true) — never thrown, always structured
{ "ok": false, "code": "REFERENCE_NOT_ATTACHED", "message": "0/1 reference images attached; nothing was sent", "recoverable": false, "details": {}, "screenshot": "/…/reference-not-attached.png" }Code | Meaning | Retry? |
| Chrome is on the Google sign-in page | sign in first |
| the keyframe did not land in the composer; nothing sent | fix the path |
| Flow refused the prompt | rewrite prompt |
| no output within |
|
| another tool call holds this server's tab | wait, retry |
| a button/menu was not where expected (rows in | see Troubleshooting |
|
| check |
Model | Credits | Notes |
Veo 3.1 - Lite | 5 (4/6/8 s) | the only model Scene Builder Extend uses |
Veo 3.1 - Fast | 10 | |
Veo 3.1 - Quality | 100 | |
Omni Flash | 15 / 20 / 25 / 30 | 4 / 6 / 8 / 10 s; video-to-video edits 40 |
Scene Builder Extend hop | 5 | 7 s, Veo 3.1 - Lite |
Defaults work on macOS. Override with ~/.config/google-flow-mcp/config.json (npx -y @park-sang-gwon/google-flow-mcp init writes one) or FLOW_MCP_* environment variables:
Key | Env | Default |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The server speaks MCP over stdio; a raw JSON-RPC client is ~40 lines:
import json, subprocess, itertools
proc = subprocess.Popen(["npx", "-y", "@park-sang-gwon/google-flow-mcp"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, text=True, bufsize=1)
ids = itertools.count(1)
def rpc(method, params=None, notify=False):
msg = {"jsonrpc": "2.0", "method": method, "params": params or {}}
if not notify: msg["id"] = next(ids)
proc.stdin.write(json.dumps(msg) + "\n"); proc.stdin.flush()
if notify: return None
for line in proc.stdout:
if line.startswith("{") and json.loads(line).get("id") == msg["id"]:
return json.loads(line)["result"]
rpc("initialize", {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "me", "version": "0"}})
rpc("notifications/initialized", notify=True)
res = rpc("tools/call", {"name": "flow_status", "arguments": {}})
print(json.loads(res["content"][0]["text"]))Only JSON-RPC frames are written to stdout; logs go to stderr and ~/.google-flow-mcp/logs.
Symptom | What to do |
| Sign in once in the Chrome window the server opened, then call |
| A tab with a frozen renderer blocks Playwright for everyone. Run |
| Flow changed a label. Compare the rows with |
| The path must be absolute and exist on this machine; large PNGs upload slowly — JPEG is faster |
The agent keeps "announcing" but not generating | The server nudges it twice; if it still stalls the settings' "confirm before generating" was not set to Never — rerun the tool |
Two agents on one machine | Fine: each server owns one tab in the shared Chrome. Just keep their |
Logs: ~/.google-flow-mcp/logs/server-YYYY-MM-DD.log · screenshots of every phase and failure: ~/.google-flow-mcp/screenshots/.
Is this an official Google product? No. It is an unofficial automation of the Flow web UI; it uses no private API and does nothing you could not do by hand in the same browser.
Does it store my Google password? Never. You sign in inside Chrome; the session lives in the Chrome profile directory. Treat ~/.google-flow-chrome like a password store.
Can it download the finished scene from Scene Builder? Not in the current Flow build — the export renders but no file reaches an automated tab. Download the clips by media_id and concatenate locally (the seam is frame-exact).
Where is "Jump to"? The current Scene Builder menu only offers "Add clip" and "Extend", so there is nothing to automate yet.
Which Flow UI languages work? Korean and English are matched; other languages need their strings in src/flow/labels.ts — flow_inspect shows you exactly what is on screen.
Adding a clip to an existing scene (asset picker)
Scene export once Flow lets an automated tab receive the file
Characters and the Tools gallery
More UI languages
npm install
npm run check # format · lint · typecheck · unit + stdio contract tests · docs freshness
npm run build
npx tsx scripts/call.ts flow_status # run one tool over real stdioSee docs/development.md for the flow_inspect discovery loop and docs/architecture.md for the design. Live tests that touch Flow are gated behind FLOW_E2E=1. Please follow Conventional Commits (CONTRIBUTING.md).
MIT. Google Flow, Veo and Nano Banana are trademarks of Google LLC; this project is not endorsed by or affiliated with Google.
Attach to the dedicated Chrome (launching it if needed), open a tab owned by this server and load Google Flow. Other tools connect on demand, so this is mainly a warm-up and login check. If logged_in is false, sign in once in the Chrome window.
| Name | Required | Description | Default |
|---|---|---|---|
| open_url | No | URL to open instead of the Flow home page (e.g. a project URL) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tab_url | Yes | |
| cdp_port | Yes | |
| logged_in | Yes | |
| attached_existing | Yes | true when a Chrome was already listening on the CDP port |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behaviors beyond the annotations: it may launch Chrome if needed, opens a tab owned by the server, and can perform a one-time sign-in. These side effects align with the readOnlyHint=false and idempotentHint=true annotations and add meaningful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The primary action is front-loaded, the purpose is stated, and the conditional login behavior is included without redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter with a full output schema, the description covers what the tool does, when to use it, and key side effects. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so open_url is already well documented in the schema as a URL to open instead of the Flow home page. The description adds no extra parameter semantics, but the baseline of 3 is appropriate because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: attach to the dedicated Chrome instance, open a server-owned tab, and load Google Flow. It also clarifies the tool's role as a warm-up and login check, distinguishing it from on-demand sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is mainly a warm-up and login check while other tools connect on demand, giving clear usage context. It also provides the conditional action for logged_in being false, but it does not name specific sibling alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate images through the Flow agent composer (Nano Banana models) and download them. Spends Flow credits when auto_confirm=true; auto_confirm=false prepares and verifies without sending. resume=true only waits for / downloads an in-flight generation.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of images to request | |
| model | No | nano-banana-pro | |
| ratio | No | 1:1 | |
| job_id | No | ||
| prompt | Yes | ||
| resume | No | ||
| output_dir | Yes | ||
| project_url | Yes | ||
| auto_confirm | No | ||
| reference_images | No | Local image paths attached as visual references |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| files | Yes | Absolute paths of downloaded outputs |
| model | Yes | |
| ratio | Yes | |
| job_id | Yes | Pass back with resume=true to pick up this generation after a restart |
| prompt | Yes | The exact instruction sent to the Flow agent |
| status | Yes | |
| duration | No | |
| media_ids | Yes | |
| elapsed_ms | Yes | |
| screenshot | No | |
| approval_text | Yes | Text of the approval card if one was shown (contains the credit cost) |
| references_attached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds meaningful behavioral detail beyond the annotations by disclosing the credit-spending side effect and the 'prepares and verifies without sending' dry-run mode. This complements the destructiveHint/readOnlyHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences front-load the core action and then cover credit spending, dry-run behavior, and resume behavior. Every sentence carries operational weight with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter open-world tool with destructive and cost implications, the description conveys the most important operational semantics and benefits from annotations and an output schema. Still, required-parameter meanings and prerequisites like an active Flow connection/project are left to inference, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description compensates mainly for auto_confirm and resume. It does not explain required parameters like prompt, project_url, and output_dir, nor does it add context for model, ratio, count, job_id, or reference_images beyond what their names/defaults imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action—generate and download images—and names the Flow agent composer (Nano Banana models) as the resource. It clearly separates image generation from the sibling video generation tool, though it does not explicitly distinguish itself from a download-only sibling like flow_media_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful mode-based guidance: auto_confirm=false validates without spending credits, auto_confirm=true sends and spends, and resume=true only waits for/downloads an in-flight generation. However, it does not explicitly state when to prefer this tool over flow_media_download or what preconditions like an active Flow connection/project are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate one video through the Flow agent composer and download it. Spends Flow credits when auto_confirm=true. Call with auto_confirm=false first: the prompt, settings and reference image are prepared and verified but nothing is sent. resume=true skips the composer and only waits for / downloads an in-flight generation (after a crash or timeout).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | veo-3.1-fast | |
| ratio | No | 9:16 | |
| job_id | No | Job to resume; defaults to the latest in-flight job for project_url + output_dir | |
| prompt | Yes | Scene description; the tool wraps it into an instruction with model/ratio/duration | |
| resume | No | ||
| duration | No | Seconds; 10 is Omni Flash only | |
| edit_mode | No | Edit the last video of the current agent session instead of generating a new one | |
| output_dir | Yes | Local directory for the downloaded file (flow_<id8>_<job>.mp4) | |
| project_url | Yes | Project the video is generated in; outputs are saved to that project | |
| auto_confirm | No | false = prepare only (0 credits); true = send and wait | |
| reference_images | No | Local image paths attached as the first frame / reference |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| files | Yes | Absolute paths of downloaded outputs |
| model | Yes | |
| ratio | Yes | |
| job_id | Yes | Pass back with resume=true to pick up this generation after a restart |
| prompt | Yes | The exact instruction sent to the Flow agent |
| status | Yes | |
| duration | No | |
| media_ids | Yes | |
| elapsed_ms | Yes | |
| screenshot | No | |
| approval_text | Yes | Text of the approval card if one was shown (contains the credit cost) |
| references_attached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals that credits are only spent when auto_confirm=true, that the preparation phase sends nothing, and that resume skips the composer to wait for or download an in-flight job. These are important side-effect and recovery behaviors the agent needs to know before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the core action, the credit-safe preparation rule, and the resume recovery path. There is no filler, tautology, or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with an output schema and side effects, the description covers the full lifecycle: prepare, confirm/send, wait/download, and resume after failure. Sibling tools like flow_status and flow_media_download handle adjacent concerns, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 73%, so the schema already documents most parameters. The description adds meaningful scenario-level meaning to auto_confirm, resume, prompt, and reference_images, e.g. 'nothing is sent' at auto_confirm=false and 'skips the composer' for resume. This compensates well for parameters whose semantics are only partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate one video through the Flow agent composer and download it,' a specific verb-resource-action combination that clearly distinguishes it from siblings like flow_generate_image. It also explains the two-phase generation flow, which further clarifies what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to call with auto_confirm=false first to prepare and verify, then proceed to auto_confirm=true to spend credits and send. It also defines resume=true for recovering in-flight generations after a crash or timeout, giving clear when-to-use and sequencing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot interactive elements, optionally perform one action (click/hover a button matched by text or aria-label regex, press a key, or navigate), then return the elements that appeared/disappeared. This is how selectors are discovered when Flow changes its UI; paste the rows into a bug report. Never generates anything.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Viewport coordinates [x, y] to click/hover instead of a target (from a previous row @x,y) | |
| key | No | Key to press for action=press, e.g. Escape | |
| url | No | URL for action=goto | |
| find | No | Regex over visible text nodes; matches are returned with their position | |
| text | No | Text to type for action=type (after clicking target/at if given) | |
| media | No | Also list img/video elements that reference a Flow media id | |
| action | No | none | |
| region | No | Restrict rows to a viewport region | all |
| target | No | Regex matched against button/menu item text and aria-label (for click/hover), or "media:<id-prefix>" to target a media tile | |
| settle_ms | No | Wait after the action before the second snapshot | |
| screenshot | No | ||
| watch_network | No | Record network requests made during the action and settle window (method, status, type, URL) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| rows | Yes | All rows in the region after the action (capped at 300) |
| added | Yes | |
| media | No | id8|TAG|@x,y wxh for each media element |
| matches | No | |
| removed | Yes | |
| requests | No | METHOD status content-type URL (capped at 80) |
| screenshot | No | |
| before_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already signaling readOnlyHint=false and openWorldHint=true, the description adds meaningful behavioral context by explaining the snapshot-action-diff flow and the exclusion 'Never generates anything.' It could further disclose side effects of actions like click/type/goto, but the annotations and action list already imply mutability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core behavior in the first sentence. The extra sentences about selector discovery and 'Never generates anything' are useful context, though the bug-report mention is slightly tangential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 12 parameters, but the schema covers most of them and an output schema exists. The description supplies the missing usage context and distinguishes the tool from generation/screenshot siblings, making it sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 83% of parameters with descriptions, so the baseline is 3. The description adds minimal parameter-level meaning beyond noting click/hover by text or aria-label regex and pressing keys or navigating, which mostly restates schema information already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it snapshots interactive elements, optionally performs one action, and returns elements that appeared/disappeared. It also clearly differentiates from siblings like flow_screenshot and flow_generate_* by emphasizing selector discovery and 'Never generates anything.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: 'This is how selectors are discovered when Flow changes its UI.' It lacks explicit when-not-to-use instructions or named alternatives, but the strong purpose statement and sibling context make the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download one Flow media item (video or image) by its media id using the logged-in browser session. Ids come from the generation and scene tools or from flow_project_open.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | File name without extension; default flow_<id8>_manual | |
| media_id | Yes | Media uuid from media.getMediaUrlRedirect?name=<id> | |
| output_dir | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| path | Yes | |
| bytes | Yes | |
| content_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (idempotentHint=true, destructiveHint=false, openWorldHint=true), and the description adds a genuinely behavioral detail beyond those hints: the operation relies on the logged-in browser session, signaling an authenticated-session dependency rather than an API-key path. No contradiction with readOnlyHint=false since downloading writes a file to output_dir.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action, scope, and mechanism are front-loaded in sentence one; sentence two contributes only the ID provenance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema documents return values and annotations cover idempotency and destructiveness, so the description doesn't need to repeat those. Its real gap is the required output_dir parameter — completely unexplained — plus unstated file-extension and overwrite behavior. For a 3-parameter tool that is a meaningful omission, though the workflow context is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: media_id and filename are documented in the schema, and the description reinforces media_id provenance by noting the item type and source tools. However, the required output_dir parameter has no description in either the schema or the tool description — the agent is left guessing whether it is a directory path or full path and whether it gets created. The description partially compensates for the coverage gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Download one Flow media item (video or image) by its media id' — making the operation unambiguous and scoped. The second sentence grounds the identifier ('Ids come from the generation and scene tools or from flow_project_open'), positioning this tool as the retrieval step alongside generation/scene siblings. It stops short of explicitly contrasting with a similar sibling, but the verb alone separates it cleanly from generate/screenshot/inspect tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: the 'logged-in browser session' clause implies a flow_connect prerequisite, and the ID-provenance sentence tells the agent this tool is used downstream of generation/scene tools. However, it never explicitly states when not to use it or names an alternative path, so it lacks exclusions and stays below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate the owned tab to a Flow project URL and report how many media items the grid shows. Generation tools call this implicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| project_url | Yes | https://labs.google/fx/<locale>/tools/flow/project/<uuid> |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| media_ids | Yes | Media ids currently visible in the grid, newest first as rendered |
| project_id | Yes | |
| media_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds concrete behavioral detail beyond the annotations: it navigates the owned tab, reports grid media count, and is invoked implicitly by generation tools. These behaviors are not captured by the structured annotations and help the agent understand what will happen.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core behavior and an important implicit-call note without wasted words. The key action is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single documented parameter, existing output schema, and annotations, the description covers what the tool does and when it is used implicitly. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully documented in the schema with type, format, and an example URL pattern. The description adds no additional parameter semantics, so the baseline for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action: navigating the owned tab to a Flow project URL and reporting the media item count. This clearly distinguishes the tool from siblings like flow_status or flow_generate_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that generation tools call this tool implicitly, which tells an agent when not to call it directly. It does not list alternative tools or precise when-to-use conditions, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a project media item's menu and "Add to Scene → Create scene", then open the new Scene Builder view. Returns the scene URL to pass to flow_scene_extend / flow_scene_status / flow_scene_download. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| media_id | Yes | Media id (or 8+ char prefix) of a video already in the project grid | |
| project_url | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| clips | Yes | |
| scene_id | Yes | |
| scene_url | Yes | |
| total_duration_s | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent operation. The description adds useful behavioral detail beyond annotations: it costs no credits and returns a scene URL. No contradiction with the annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, then adds downstream context and cost info. The UI-menu navigation detail is somewhat unnecessary for an API agent, but it does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and description together explain the return value, and the description notes cost and downstream usage. However, one required parameter (project_url) is left undocumented in both schema and description, leaving a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only media_id is documented in the schema; project_url has no description. The description references a 'project media item', which hints at media_id, but it does not clarify what project_url is or provide enough compensation for the 50% schema description coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly identify the operation as creating a scene from a project media item. It also distinguishes itself from sibling tools by noting the returned scene URL is meant to be passed to flow_scene_extend, flow_scene_status, or flow_scene_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: this is the creation step that produces a scene URL consumed by related scene tools. It does not explicitly state when not to use it, but the downstream-tool mention gives an agent enough guidance to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scene Builder "Extend": generates a 7-second continuation of the clip at after_clip_index (must be the last clip) with Veo 3.1 - Lite and downloads it as a separate media file. Spends credits when auto_confirm=true; auto_confirm=false opens the extend prompt, fills it, takes a screenshot and cancels. Safe to retry: if the extension was already generated (clip present at after_clip_index+1, or resume=true after a crash) it is downloaded instead of generated again.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | ||
| prompt | Yes | What happens next; Flow continues motion and audio from the last frames | |
| resume | No | ||
| scene_url | Yes | ||
| output_dir | Yes | ||
| auto_confirm | No | ||
| after_clip_index | Yes | Index of the clip to extend (0-based); must be the last clip |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| file | No | |
| clips | Yes | |
| model | Yes | |
| job_id | Yes | |
| status | Yes | |
| media_id | No | |
| scene_url | Yes | |
| clip_index | Yes | Index of the extension clip in the timeline |
| elapsed_ms | Yes | |
| screenshot | No | |
| hop_seconds | Yes | |
| total_duration_s | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as non-read-only, destructive, and idempotent, and the description adds valuable specifics: it spends credits when auto_confirm=true, and when auto_confirm=false it opens the prompt, fills it, screenshots, and cancels. The retry behavior and 'download instead of generate again' logic meaningfully explain what idempotency means in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler: main action, side effects and spending behavior, then retry semantics. It is front-loaded with the operation and keeps important caveats compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool, the description covers the essential call path: last-clip target, continuation generation, download, credit spending, and retry behavior. The presence of an output schema means return values do not need to be described; the main remaining gaps are the roles of scene_url and job_id, which are relatively minor but not fully self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description must compensate, and it does for several key parameters: auto_confirm, resume, after_clip_index, and the download behavior tied to output_dir. However, scene_url and job_id are never explained, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action: 'generates a 7-second continuation of the clip at after_clip_index' using 'Veo 3.1 - Lite', then states it downloads the result as a separate media file. This clearly identifies the verb, resource, and scope, and distinguishes it from sibling tools like flow_scene_add or flow_generate_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the operation applies specifically to the last clip, and the auto_confirm true/false split tells an agent what will happen in each mode. It does not explicitly name alternative tools or exclusion cases, but the scene-builder extension purpose is unambiguous enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Scene Builder view and report its clips (index, duration) and total length, plus whether an extension is still rendering. with_media_ids selects each clip to read its media id (slower). Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_url | Yes | ||
| with_media_ids | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| clips | Yes | |
| scene_id | Yes | |
| generating | Yes | |
| total_duration_s | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it reports that the operation opens a view, exposes a performance tradeoff for with_media_ids, and states that no credits are consumed. It does not cover failure modes, but the additional context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main action and output are stated first, followed by the optional parameter behavior and cost detail. Every sentence adds value with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter inspection tool with an output schema, the description covers the key context: what it reports, the optional flag's effect, and the cost. The main gap is explicit guidance on choosing it over related sibling tools, but that is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
with_media_ids is well explained: it makes the tool read each clip's media id and is slower. scene_url is left to inference from its name and URI format, so the description only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: open a Scene Builder view and report clips by index and duration, total length, and rendering status. This is specific enough to distinguish from sibling tools like flow_screenshot or flow_generate_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear enough to infer when it should be used, and the description notes that with_media_ids is slower and that the operation costs no credits. However, it does not explicitly compare against alternatives such as flow_status or flow_inspect, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a PNG of the tab this server owns and return its absolute path. Useful to see what the agent or Scene Builder is showing.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Short label used in the file name | |
| full_page | No | Capture the whole scrollable page instead of the viewport |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior: it saves a PNG file and returns its absolute path. Annotations already indicate the operation is read-only, idempotent, and non-destructive, so the description adds useful file-output context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary behavior is front-loaded, and the second sentence justifies the tool's usefulness without repeating the schema or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with zero required parameters, full schema coverage, an output schema, and comprehensive annotations, the description provides enough operational context. It states what happens, what is returned, and why an agent would use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with both 'label' and 'full_page' already described in the schema. The tool description does not need to add parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Save a PNG of the tab this server owns') and its result ('return its absolute path'). It clearly identifies the target resource as the screenshot of the Flow tab, and no sibling tool performs the same function, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a clear use case: 'Useful to see what the agent or Scene Builder is showing.' It does not explicitly state when not to use it or name alternatives, but the context is sufficient for a tool with no overlapping screenshot sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report browser connection, login state, the current Flow project/scene, the running tool and in-flight jobs. Never touches the page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | No | |
| scene_id | No | |
| connected | Yes | |
| logged_in | Yes | |
| project_id | No | |
| running_tool | No | |
| jobs_in_flight | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the explicit behavioral guarantee 'Never touches the page,' which is valuable beyond the annotations. It also clarifies that it reports in-flight jobs and the running tool, giving the agent a clear mental model of what the call observes without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The primary action and scope are front-loaded, and the safety note is appended efficiently. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, rich annotations, an output schema, and a precise enumeration of reported state, the description is complete. An agent can confidently invoke this tool to assess connection, login, project, and job status without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 applies, and the description appropriately focuses on behavior and output content rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names exact resources: browser connection, login state, current Flow project/scene, running tool, and in-flight jobs. It clearly distinguishes itself from sibling tools like flow_screenshot or flow_connect by stating what status information it provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever an agent needs an overview of connection, login, project, and job state. However, it does not explicitly mention alternatives or state when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool addresses a distinct part of the workflow: connection/status, page observation, project opening, generation, media download, and scene operations. Similar actions like generating a video versus extending a scene are clearly separated by context and dedicated names.
All tools share a useful flow_ prefix and consistent snake_case, but the word order is mixed: flow_generate_video is verb-object while flow_project_open, flow_media_download, and flow_scene_add are object-verb. This is still readable but does not follow a single predictable verb_noun pattern.
Eleven tools is well-scoped for the Google Flow domain, covering browser connection, inspection, project navigation, generation, downloads, and scene extension without redundancy. Each tool earns its place and the count is within the ideal range.
The core end-to-end workflows are covered: connect, open a project, generate video/image with confirmation and resume support, download media, and extend scenes. Minor gaps exist around enumerating projects or arbitrary media IDs without a prior URL or generation result, but these are workable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Build and run visual creative-production workflows from your AI agent.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ParkSangGwon/google-flow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
