Google Flow Browser MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Tools are mostly distinct, covering connection, generation, characters, scenes, queue, and UI automation. Minor overlap exists between flow_status and flow_queue_status (both report queue state), and flow_use_tool vs flow_use_grid_architect (specialized case), but descriptions and parameters generally disambiguate clearly.
Naming Consistency4/5
All tools share the 'flow_' prefix and use snake_case, with a predominantly verb-noun pattern (e.g., flow_generate_image, flow_create_character). A few object-led names like flow_account_check, flow_queue_status, and flow_queue_reset deviate from the verb-first convention, but the overall pattern remains readable and predictable.
Tool Count4/5
With 19 tools, this is on the heavier side but justified by the broad scope of Google Flow automation: connection, media generation, character/scene management, queue control, and UI discovery. The count feels appropriate for the range of capabilities, though it approaches the threshold where complexity can become unwieldy.
Completeness3/5
Core workflows are covered, but there are notable gaps: no update/delete for characters or scenes, no list-scenes tool (while list-characters exists), and video generation stops short of triggering the final generation, leaving a dead end. Generic flow_use_tool and flow_discover_ui offer workarounds, but the surface is not fully self-sufficient for entity lifecycle management.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and requirements. It only says 'create a new scene' without mentioning that it may reuse or create a project, require existing characters, or any other behavioral details. The schema description for project_name suggests reuse logic, but the description itself does not convey this.
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, front-loaded sentence with no waste. It immediately states the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is too minimal. It fails to explain the campaign/project matching logic, character requirements, or the meaning of a 'scene'. The schema provides some parameter-level detail but not the overall tool behavior or expected outcomes.
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?
The input schema covers all parameters with descriptions, so the baseline is 3. The description's mention of 'characters and prompt' merely echoes the schema and adds no additional semantic meaning beyond what is already documented.
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 action ('Create') and the resource ('a new scene in Google Flow Scenes'), and mentions key inputs ('characters and prompt'). It is specific enough to distinguish from sibling tools like flow_create_character or flow_generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., characters must exist), and no exclusions. It lacks any usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'open' and 'fill configuration parameters' but does not explain whether this executes the tool, requires a connection, or affects project state. The presence of campaign and project_name parameters suggests side effects, but they are not explained, making the behavior unclear.
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 concise sentence that immediately states the core function and optional parameter filling. It is front-loaded and contains no redundant information, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema, so the description should explain the tool-opening flow, how project matching works, and what the user can expect as a result. None of this is present, leaving significant gaps for the agent. The description is too minimal for the complexity of the tool.
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?
The input schema documents all four parameters with a high coverage, so the baseline is 3. The description adds minimal meaning by clarifying that 'params' are configuration parameters and 'tool_name' is the tool's name, but it does not elaborate on campaign or project_name behavior. The schema already covers the basics, so the description does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool opens any tool by name in Google Flow and optionally fills configuration parameters. This distinguishes it from siblings like flow_generate_image or flow_use_grid_architect, which are specific tool actions. The verb 'open' is slightly ambiguous (whether it executes or navigates), but the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'any tool by name' implies a generic fallback, but it does not explicitly state when to use this tool versus dedicated siblings. No exclusions or alternative recommendations are provided, leaving the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool opens a page and lists characters but does not disclose potential side effects, such as creating a new project if none matches (as implied by the schema's project_name description). Lacks details on permissions or reversibility.
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?
Single sentence, front-loaded with action and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple navigation/listing tool but lacks context on project selection mechanism and output nature. With no output schema or annotations, it could benefit from explaining the relationship between campaign and project_name and whether the list is returned as data.
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 has 100% coverage, so baseline is 3. The description adds no parameter-specific information; it relies entirely on schema descriptions for campaign and project_name.
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?
Description uses specific verb 'open' and resource 'Characters page', and further clarifies it lists existing characters. This clearly distinguishes it from sibling tools like flow_create_character and flow_import_character, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as flow_create_character or flow_import_character. The description implies usage for viewing existing characters but doesn't state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the high-level action, without detailing side effects (e.g., overwriting existing characters), validation of the JSON, error handling, or any prerequisites. This is a significant gap for an import tool.
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, front-loaded sentence with no filler or redundant information. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose is clear and the schema covers parameters, but the description lacks usage guidance relative to sibling tools and does not disclose behavioral traits (e.g., whether it overwrites or merges). For a tool with no annotations and no output schema, this is adequate but leaves gaps for an agent deciding between import and create.
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?
The input schema provides descriptions for all three parameters (campaign, file_path, project_name), giving 100% schema coverage. The description itself adds no parameter-specific detail, so the baseline of 3 is appropriate since the schema handles parameter semantics.
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 uses a specific verb ('Import') with a clear resource ('character') and source/destination ('saved JSON file' into 'Google Flow'). This clearly distinguishes it from siblings like flow_create_character (which creates from scratch) and flow_open_characters (which opens existing characters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a saved JSON character file exists, but it offers no explicit when-to-use or when-not-to-use guidance, and does not mention alternative tools such as flow_create_character. The context is inferred from the phrase 'saved JSON file' rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral trait: it updates the internal selectors map as a side effect, which is useful context beyond the tool's primary action. However, with no annotations provided, the description carries the full burden but does not mention authentication requirements, failure modes, or rate limits. This partial transparency warrants a mid-range score.
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 exactly two sentences with no unnecessary words. The first sentence states the action and scope, while the second explains the side effect. This is concise, front-loaded, and every sentence earns its place.
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 rich schema that explains pages and overrides, the description is largely complete. It states the purpose and side effect, which is sufficient for an agent to understand the tool's typical use. However, it lacks explicit prerequisites (e.g., needing a connection via flow_connect) and error behavior, leaving some contextual gaps.
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% according to the context signals, meaning all four parameters are thoroughly documented in the schema, including the detailed page options and url override. The tool description itself adds no parameter-level detail, but the baseline of 3 is appropriate when the schema already covers parameters comprehensively.
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 navigates to a Google Flow page and discovers all interactive elements (buttons, inputs, links, headings), and updates the internal selectors map. This is a specific verb+resource combination that clearly distinguishes it from sibling tools like flow_screenshot or flow_open_characters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies a setup step for automation ('Updates the internal selectors map for robust automation') but does not mention exclusions, prerequisites, or alternative tools. Sibling tools such as flow_connect and flow_screenshot exist, but no direct comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It says 'open' and 'list' but does not disclose side effects, whether it navigates the UI, requires authentication, or returns a list format. The behavioral scope is implied but not explicit.
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, direct sentence with no filler. It is front-loaded with the action and resource, making it immediately understandable.
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?
For a simple tool with no parameters and no output schema, the description is sufficient to convey the core function. It could mention what the 'list' returns, but the tool's simplicity and the clarity of the action make it largely complete.
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 tool has zero parameters, and schema coverage is 100% (empty schema). The description doesn't need to explain parameters, and the baseline of 4 applies as no additional parameter information is necessary.
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 a specific action (open and list) on a specific resource (Google Flow Tools Gallery). It distinguishes itself from siblings like flow_open_characters and flow_use_tool by naming the exact gallery and listing action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to prefer this over sibling tools like flow_use_tool or flow_discover_ui, or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Verify' but does not disclose what happens on success/failure, whether it returns a boolean, throws an error, or has side effects. For a check tool, this lack of behavioral detail is a significant gap.
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 with leading verb and no fluff. It conveys the core purpose efficiently without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with no parameters and no output schema, the description is partially complete. It explains what it does but not what the agent should expect as a result (e.g., does it return a Boolean, throw an exception, or print a message?). The mention of 'Default' also lacks context about how the expected email is configured, leaving some ambiguity.
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 tool has zero parameters, so the description does not need to explain any. The baseline for 0 params is 4, and the description correctly avoids adding unnecessary parameter details since the schema is empty.
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 a specific action (verify) and the exact subject (logged-in Google account) against an expected configured email. This distinguishes it from sibling tools like flow_status or flow_connect, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to ensure the correct Google account is active, but it does not explicitly state when to use it versus alternatives. For example, it doesn't mention using it after flow_connect or before other operations. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the action and does not mention side effects, authentication requirements, error handling (e.g., what if no file exists), or return format. This is a significant gap for a tool with no annotation support.
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, concise sentence that immediately states the tool's purpose. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is adequate but incomplete. It does not explain what the user receives (e.g., file content, download link) or how errors are handled (e.g., no recent file). This leaves room for ambiguity.
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?
There are zero parameters, so the schema provides no semantics. The baseline for 0 params is 4, and the description doesn't need to add parameter info. It correctly avoids extraneous details.
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 action ('Download') and the specific resource ('the most recently generated file from Google Flow'). It distinguishes itself from sibling tools like generation or connection tools by focusing on the download action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need the latest file), but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. With many sibling tools, more explicit guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It says the tool 'open[s]' and 'fill[s]' settings but does not mention side effects, prerequisites, whether it creates or reuses projects, or what the agent should expect after invocation. This leaves significant ambiguity for a UI-automation tool.
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 two sentences and front-loads the primary action. Every phrase earns its place: the resource, the key settings, and the batch campaign use case. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the main purpose and the batch use case, and the schema fully documents parameters. However, there is no output schema, no annotation, and the description does not state prerequisites, expected outcomes, or side effects. It is minimally sufficient but has clear gaps for a complex UI automation tool.
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%, so the baseline is 3. The description repeats several parameter names (theme prompt, shot prompts, engine, ratio, visual logic) but does not add meaning beyond the schema's own field descriptions, such as campaign reuse behavior or reference image handling.
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 opens with a specific action and resource ('Open Grid Architect in Google Flow') and lists the exact settings it fills (theme prompt, shot prompts, engine, ratio, visual logic). It clearly differentiates from siblings like flow_generate_image by emphasizing batch shot generation for brand campaigns.
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 provides a clear use case: batch shot generation for brand campaigns. It does not explicitly name alternatives or state when not to use it, but the context strongly implies this tool is for multi-shot Grid Architect workflows rather than single-image generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary effects (closing browser and cleaning up connection), but with no annotations, it does not cover prerequisites, idempotency, or consequences for existing sessions. It is minimally transparent but lacks depth.
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?
A single, direct sentence that states the purpose without any filler. It is appropriately concise and front-loaded.
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?
The description is sufficient for a simple zero-parameter teardown tool, covering its main effect. However, it could have mentioned that it reverses flow_connect or is safe to call when already disconnected, making it slightly incomplete.
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 tool has zero parameters, and schema coverage is trivially 100%. The description adds no parameter-level details, but none are needed; baseline for zero-parameter tools applies.
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's action: closing the browser and cleaning up the MCP connection to Google Flow. This distinguishes it from siblings like flow_connect, which is presumably the setup counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool or when to avoid it. The sibling context implies it is the teardown counterpart to flow_connect, but the description does not state this relationship or provide usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'check' indicates a read-only operation, and the description enumerates the data returned (active, pending, history). It does not disclose rate limits, ordering, or side effects, but for a simple status-checking tool, the behavioral context is reasonably clear.
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 verb and resource, followed by a concise list of what the queue status covers. Every word earns its place; no filler or repetition.
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?
For a simple tool with one optional parameter and no output schema, the description covers the high-level return categories (active, pending, completed, failed history). It could be more explicit about the shape of the response, but given the tool's simplicity, it is substantially complete.
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%: the single parameter history_limit has its own description in the schema. The tool description adds no extra parameter details, so per baseline rules with high coverage, a score of 3 is appropriate.
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 uses the specific verb 'check' with the resource 'job queue' and explicitly enumerates what is inspected: active job, pending queue, completed and failed job history. This clearly distinguishes it from siblings like flow_status (general status) and flow_account_check (account-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to inspect the job queue and its states. However, it does not provide explicit when-to-use vs alternatives or mention exclusions, leaving the guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'check' implies a read-only operation, but the description does not explicitly disclose side effects, failure behavior, or whether it requires a connection. It lists what it checks but not what happens if components are missing, leaving some behavioral ambiguity.
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, front-loaded sentence that directly states the tool's purpose and the components it covers. Every word contributes meaning, with no redundancy or filler.
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 low complexity (one optional parameter, no output schema), the description adequately covers the tool's purpose and scope. It could be improved by mentioning what the return value looks like or how the 'full' parameter affects output, but the schema already covers the parameter, and for a status check this is reasonably complete.
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?
The schema provides 100% coverage for the single 'full' parameter with its own description. The tool description adds no additional meaning about the parameter, 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.
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 current connection status and enumerates the exact components (browser connected, Flow page loaded, account verified, job queue state). This is a specific verb+resource+scope that distinguishes it from narrower sibling tools like flow_account_check and flow_queue_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a general status check, but does not explicitly state when to use this tool instead of individual checks (e.g., flow_account_check or flow_queue_status). No exclusions or alternative recommendations are provided, so guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the exact steps (launch Chrome, connect CDP, navigate, verify) and a warning about headless mode, which is useful. However, it omits side effects (e.g., opening a visible browser window) and does not clarify what happens if already connected or how 'verify account' behaves on failure.
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 concise sentence that front-loads the main action and includes all key steps without wasted words. It is efficient and easy to parse, earning a perfect score.
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?
For a setup/connection tool with no output schema and no annotations, the description covers the main workflow and warns about headless usage. It is mostly complete, though it could mention idempotency or error handling, but those are not critical for a basic connect operation.
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?
The input schema provides full descriptions for both parameters (headless and open_flow) with 100% coverage, so the baseline is 3. The tool description adds context about the overall workflow but does not add new meaning to the individual parameters beyond what the schema already states.
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 a multi-step purpose: launch Chrome with the configured Google profile, connect CDP, navigate to Google Flow, and verify account. It uses a specific verb sequence and explicitly names the resource (Google Flow), and it is easily distinguished from siblings like flow_disconnect or flow_status.
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 this is the connection/setup tool and provides a clear usage guideline for the headless parameter ('not recommended, Google Flow needs visible browser'). However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like being disconnected first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It states the action but does not disclose where the screenshot is saved, whether it returns a path or binary data, or any preconditions like having a Flow page open. This leaves gaps but the core behavior is unambiguous.
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, direct sentence that is front-loaded with the action and target. Every word contributes meaning, with no filler or 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?
For a simple tool with one optional parameter and no output schema, the description combined with the schema is largely sufficient. However, it does not mention the return value or file location, which would make it more complete. Overall it is adequate for the low complexity.
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?
The input schema covers 100% of the parameter information, including the default value and a description for 'name'. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
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 verb 'Take' and the resource 'current Google Flow page', leaving no ambiguity about what the tool does. It also distinguishes itself from the sibling tools by referring to a screenshot, which no other sibling tool explicitly does.
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 the appropriate use case: capturing the current state of the Google Flow page. While it does not explicitly mention alternatives or exclusions, the unique screenshot action makes the context clear. There are no competing sibling tools that would require explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It transparently explains the default auto_confirm behavior (filling description, clicking submit, renaming 'Untitled Character') and hints at a non-submitting mode (via the 'By default' clause), adding useful context beyond the schema.
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, and every clause adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, yet the description does not mention expected return values or outcomes (beyond an implicit rename). It covers the main creation flow but omits details about reference images, project matching, or what the agent should do with the result. This leaves some gaps for agents needing full context.
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 coverage is 100%, so baseline is 3. The description adds meaningful context for the auto_confirm parameter by explaining the default flow (clicks submit, renames), complementing the schema's terse description. This justifies a 4.
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 creates a new character in Google Flow Characters, with specific verb (create) and resource (character), and distinguishes it from siblings like flow_import_character and flow_generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to create a character) but does not explicitly state when not to use it or provide alternatives. It lacks direct comparison with related tools like flow_import_character.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses that the tool stops at 'ready-to-generate' and does not trigger the paid feature, which is the most important behavioral trait. It lacks details on side effects like project creation, but the note about the final click is highly valuable.
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 two concise sentences, front-loaded with the purpose and followed by a critical NOTE. Every word earns its place, with no redundancy or irrelevant detail.
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 10 parameters and no output schema, the description plus schema provides sufficient context for an agent to invoke the tool. It covers the main purpose and limitation, and the schema handles parameter details. Minor gap: no mention of project reuse or return behavior, but these are secondary.
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 coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'Omni Flash or Veo model' but omits 'Nano Banana 2' listed in the schema, and 'configures settings' is vague. The schema descriptions are more detailed and include cross-tool references like flow_list_mention_options.
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's purpose: 'Set up a video generation in Google Flow' with specific actions like filling prompt and selecting model. It distinguishes from sibling flow_generate_image by focusing on video and explicitly noting it does not click final Generate.
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 provides clear context for video generation setup and includes a critical caveat about the paid Generate feature. However, it does not explicitly mention alternatives (e.g., use flow_generate_image for images) or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It transparently states the side effect of opening Flow's '@' reference popup and reading its options, which goes beyond a generic 'list' description. It does not detail safety permissions, but the read-only nature is inferred and no harmful behavior is hidden.
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, front-loaded sentence that is both concise and information-dense. It includes the action, target, mechanism, and context without redundancy or filler.
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?
The description sufficiently explains the tool's purpose and behavior for a listing tool. It lacks an explicit return format, but that is partially mitigated by the absence of an output schema and the simplicity of the feature. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both 'campaign' and 'project_name' (100% coverage). The tool description adds no additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('images and characters'), and the context ('current project' and 'via @name in an image/video prompt'). It distinguishes this from sibling tools like flow_open_characters by specifying the popup-reading mechanism.
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 provides clear context on when to use the tool (when needing @name references for image/video prompts) and implies the popup interaction. It does not explicitly name alternatives or exclusions, so it stops short of a 5 but is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the action is 'forceful' and targets stuck jobs, implying a destructive/resetting behavior. However, it does not disclose potential side effects (e.g., loss of queued jobs, irreversibility, or required permissions), which are important for a reset operation.
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 two sentences long, with the primary action front-loaded in the first sentence. The second sentence adds valuable usage context without any fluff or redundancy. Every word earns its place.
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?
For a simple, zero-parameter tool, this description covers the purpose and the specific situation. There is no output schema, and the tool's return behavior is not described, but for a queue reset, the main point is the action itself. A small note about consequences (e.g., pending jobs may be cleared) would make it more complete, but it's adequate as is.
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 tool has zero parameters, and the input schema is an empty object. Per the rubric, 0 params is a baseline of 4. The description correctly implies no configuration is needed, so no additional parameter explanation is necessary.
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 action ('Forcefully reset the job queue') and the specific resource (the job queue). It also provides a concrete scenario (job stuck in 'running' state blocking others), which distinguishes it from sibling tools like flow_queue_status that likely just query status.
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: 'if a job is permanently stuck in "running" state and blocking other generations.' This gives clear context, though it does not mention when not to use it or explicitly name alternatives. Still, the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it explains credit consumption, the default non-destructive preparation flow, and the verification steps before clicking Generate. It also notes the model restriction and screenshot behavior. This is highly transparent.
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 appropriately sized for the complexity, front-loaded with a credit warning. It uses structured phrasing to explain both modes, with no wasted words. Each sentence contributes to understanding the tool's behavior.
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?
For a 10-parameter tool with no annotations or output schema, the description covers the essential behavior, constraints, and credit implications. It could be more specific about return values or error handling, but the core operation is well explained. The schema covers parameter details, so the description complements it effectively.
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 coverage is 100%, so the baseline is 3. The description adds critical semantics for auto_confirm (no credits by default, verification before generating) and clarifies the overall process. It doesn't explain every parameter, but the schema already does, so the description adds value beyond the schema for the most important behavior.
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 generates images via Flow, distinguishing between default preparation mode and auto-confirm generation mode. It mentions 'NANO/BANANA image models only,' scoping its purpose. The name and description together clearly identify it as an image generation tool, distinct from 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for image generation, with clear context that it works only with NANO/BANANA image models. It contrasts with video mode ('not Video'), indirectly guiding to use flow_generate_video for video. However, it doesn't explicitly name alternatives or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-flow-mcp MCP server](https://glama.ai/mcp/servers/shaig-mahmudov/google-flow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shaig-mahmudov/google-flow-mcp)

Score Badge

Copy to your README.md:

[![google-flow-mcp MCP server](https://glama.ai/mcp/servers/shaig-mahmudov/google-flow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shaig-mahmudov/google-flow-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shaig-mahmudov/google-flow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server