google-flow-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
While most tools target distinct actions, several image/video generation tools (generate_image, batch_generate_images, generate_with_face, generate_from_dossier) overlap in the core generation action and could cause misselection. Storyboard generation also overlaps with the trailer script tool. However, the descriptions do differentiate inputs and use cases.
Naming Consistency4/5
Tool names predominantly follow a verb_noun pattern (e.g., generate_image, list_projects, update_custom_tool). Minor variations like generate_with_face, generate_from_dossier, and save_media_to_local_folder deviate but remain readable and predictable.
Tool Count3/5
At 22 tools, the server is on the heavier side of the recommended range. The breadth is justified by the mix of generation, character/dossier management, custom tool operations, and trailer workflow, but it still feels slightly over-scoped.
Completeness4/5
The tool surface covers the core media generation lifecycle, including account management, image/video generation, upscaling, character consistency, dossier-based generation, custom tool management, and media retrieval/saving. Missing operations are primarily deletion (e.g., no delete_character or delete_media) and character listing, but these are minor gaps.
Average 3.6/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 carries the full burden of behavioral disclosure. It only says 'upload' without explaining authentication requirements, overwrite behavior, size limits, or what 'Google Flow' integration entails. This is insufficient for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action and resource, and has no filler. It is appropriately concise for a simple upload, though it could be more informative without becoming bloated.
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?
With four parameters, a nested object, and no output schema, the description does not adequately explain how to use the parameters together or what happens after upload. The absence of return-value information and lack of usage context make the tool under-specified for an agent to invoke confidently.
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 adds a bit of context about dossier content (characters, lore, visual rules) but does not clarify the relationship between `content` and `dossier_path` or the optional `tool_id`. It adds minimal value beyond the schema.
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 an upload action with a specific resource type (character/worldbuilding dossier) and destination (Google Flow), reinforced by examples like ACOTAR characters. While it does not explicitly differentiate from sibling tools, no sibling performs direct uploads, so the purpose is sufficiently unique.
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?
There is no guidance on when to use this tool versus alternatives such as create_character or generate_from_dossier. The examples hint at intended content but do not state prerequisites, exclusions, or preference over other tools.
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 burden of behavioral disclosure. It only states the purpose but gives no details on side effects, idempotency, permissions, what is returned, or whether naming conflicts are handled. This is a significant gap for a mutation 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, well-structured sentence. Every word contributes meaning, it is front-loaded with the core action, and there is no wasted text.
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 description is minimal and omits crucial context: how the created character card is used afterward, how it interacts with generation tools like generate_image, and what the tool returns. Given the tool's role in a pipeline, this is incomplete for an agent to understand its place.
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 adds no extra meaning beyond the schema; the 'consistent visual traits' phrase vaguely relates to the description parameter but does not add technical detail. No additional param context is provided.
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 the tool creates a reusable character card with consistent visual traits across scenes, using the verb 'Create' and a specific resource. It distinguishes from sibling image generation tools by implying cross-scene reuse, but does not explicitly name an alternative.
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 consistent characters are needed across scenes ('reusable', 'across multiple scenes'), but it does not explicitly state when to use this over generate_image or other siblings. No exclusions or alternatives are mentioned.
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 behavioral disclosure. It only states the session scope but omits details such as return format, ordering, limits, or confirmation that it is a read-only operation. This is a significant gap for a tool with no annotations.
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 verb and resource. There is no redundancy or wasted words, making it easy to parse quickly.
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 is simple with no parameters, annotations, or output schema. The description covers the core function but does not explain what the response looks like. Since no output schema exists, the description should clarify return values, which it doesn't. However, for a basic list operation, the gap is not severe.
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 schema is trivially covered. With no parameters to document, the description adds no parameter details but doesn't need to. The baseline of 4 for zero-parameter tools is appropriate.
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 the tool lists all generated images and videos in the current session. It uses a specific verb and resource, making the purpose unambiguous. However, it does not explicitly differentiate itself from sibling tools like get_media_details, though the session scope provides some distinction.
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 is provided on when to use this tool versus alternatives. The mention of 'current session' gives a context, but there is no exclusion or reference to sibling tools, so the agent is left to infer when this is the right choice.
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, and the description does not disclose side effects, prerequisites, failure behavior, or return format. It only promises 'high-fidelity' output, which is not a behavioral trait. The description carries the full burden and falls short.
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 zero filler. Every word contributes to explaining the tool's core function. This is concise and well-structured.
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?
With 5 parameters, no annotations, and no output schema, the description provides only a minimal overview. It omits return value expectations, prerequisite steps like uploading a dossier, and behavior when dossier_id is absent. The tool is not fully contextualized.
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 description does not need to explain parameters. It adds an illustrative example (Feyre & Rhysand in Velaris) but no parameter-level semantics beyond the schema. Baseline 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 states the tool generates 'high-fidelity artwork and scenes derived directly from an uploaded dossier,' with a concrete example. This distinguishes it from sibling tools like generate_image by making the dossier-based input explicit.
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 'derived directly from an uploaded dossier' implies the tool should be used when a dossier is available, but it does not explicitly compare it to alternatives or state when not to use it. The use case is implied rather than directly instructed.
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 discloses that generation runs on the user's Google account, which is useful context, but it omits key behavioral details such as whether images are returned directly or saved, whether calls are synchronous or asynchronous, and any rate limits or costs. This is a significant gap for a generation 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 short sentences, front-loads the core action, and every word contributes. It is appropriately compact.
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 7 parameters and no output schema, yet the description provides only the basic function and account context. It fails to explain what the tool returns, how it relates to sibling tools like batch_generate_images, or any post-generation steps, making it incomplete for efficient selection and invocation.
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 descriptions cover all 7 parameters, including enums for model and aspect ratio, so the description adds no additional parameter-level meaning. The baseline of 3 applies due to high schema coverage.
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 ('Generate'), names the resource ('AI image'), and identifies the underlying system ('Google Flow') and models ('Nano Banana / NARWHAL'), clearly distinguishing this from video or upscaling tools.
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 use when an AI image is needed from a prompt, but it does not provide explicit guidance on when to choose this over siblings like batch_generate_images, generate_from_dossier, or upscale_image. No exclusions or alternatives are mentioned.
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 the full burden of disclosing behavior. It only says 'Create' without mentioning what the output is, whether it returns media, if it is asynchronous, or any prerequisites like connecting an account. The behavioral profile is essentially opaque.
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 sentence of only 11 words, front-loaded with the main action and resource. Every word contributes to purpose clarity, with no filler or redundancy.
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 nested scene parameters and no output schema or annotations, yet the description only covers the high-level purpose. It does not explain return values, required scene fields, or operational context, leaving significant gaps for correct invocation.
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 description adds no parameter-specific information, but the input schema covers both top-level parameters (title and scenes) with descriptions. Baseline is 3 because schema coverage is high, though nested scene properties (prompt, shot_number) lack descriptions.
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 ('Create') and resource ('multi-frame visual sequence') and names the specific tool (Google Flow Storyboard Studio). This clearly distinguishes it from siblings like generate_image and generate_video, which produce single-frame outputs.
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 mention of 'multi-frame visual sequence' implies use for storyboards rather than single images/videos, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. No alternative tool names are referenced.
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 itself disclose behavioral traits. It only states the basic action and does not mention whether authentication is required, what the return format looks like, or that it has no side effects. This leaves a transparency 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 clear sentence, 'List all custom tools available in a Google Flow project,' with no wasted words. It is front-loaded with the action verb and resource, making it easy to parse.
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 tool is simple with one optional parameter and no output schema. The description conveys the core purpose adequately, but it does not mention any return value or connection prerequisites. Given the low complexity, this is nearly complete, though a bit more detail would be ideal.
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 fully documents the only parameter, project_id, with a clear description and optionality (100% coverage). The tool description adds no additional parameter details, so the baseline 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 explicitly states 'List all custom tools available in a Google Flow project,' which provides a specific verb (list), resource (custom tools), and scope (Google Flow project). This clearly distinguishes it from sibling tools like run_custom_tool and update_custom_tool.
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 gives no guidance on when to use this tool versus alternatives like list_media or list_projects. There is no mention of prerequisites, when to choose this tool, or any exclusions, so the agent receives no usage context.
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. It only states the action ('Execute') and the identifier, but omits behavior like whether execution is asynchronous, whether it returns a result or a job ID, what errors may occur, or whether a Google account connection is required. Sibling 'flow_status' suggests status polling, but this is not mentioned here.
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 sentence with no wasted words; the examples are integrated without bloat.
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 moderate complexity with an object parameter and no output schema, yet the description doesn't explain execution flow, return values, or prerequisites. Given the sibling flow_status, the absence of async/status info is a clear gap.
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?
All 4 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description repeats tool_id's URL/ID format but adds no extra semantic detail about inputs, prompt, or project_id.
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 'Execute' and names the resource ('custom or shared Google Flow tool'), with concrete examples like Type Overlays, Video Resizer. This clearly distinguishes from siblings such as update_custom_tool and list_tools.
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 gives examples of tool kinds it can run, implying use for those cases, but it does not explicitly state when to prefer this over built-in generators like generate_image or when not to use it. No exclusions or alternatives are mentioned.
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 disclose behavioral traits. However, it only says 'edit or update' without detailing side effects, whether the update is partial or full, or any permission requirements. This lack of behavioral transparency could leave agents uncertain about the tool's impact.
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, compact sentence that immediately communicates the tool's purpose. It contains no redundant phrasing or excessive detail, earning high marks for efficiency.
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 the absence of annotations and output schema, the description is insufficiently complete for a tool with six parameters, including nested objects. It doesn't address update semantics, such as whether unspecified fields are preserved or reset, or what the tool returns after successful execution. The brevity leaves critical gaps for agent decision-making.
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 already provides 100% coverage with detailed descriptions for all six parameters. The description merely summarizes 'code, prompt instructions, or parameters' without adding new insight into parameter semantics or usage nuances. It meets the baseline but doesn't elevate understanding.
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 function: editing or updating a custom Google Flow tool's code, instructions, or parameters. It uses specific verbs and identifies the resource, distinguishing it from sibling tools like run_custom_tool or audit_custom_tool. This is a strong, unambiguous definition.
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 does not explicitly state when to use this tool versus alternatives like creating a new tool or running it. The purpose is implied by the 'edit or update' phrasing, but no exclusions or alternative options are mentioned. It provides minimal usage guidance beyond the core 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?
There are no annotations, and the description does not disclose any behavioral traits beyond the basic action. It omits details such as whether credentials are stored, overwritten, require user consent, or what happens 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, well-structured sentence that starts with the action and includes all necessary context. Every word contributes to clarity without 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 is simple with no output schema, and the description covers its basic purpose. However, it could be more complete by mentioning whether connecting is a prerequisite for generation or how the credentials are used.
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 both 'cookies' and 'bearerToken' are already described. The tool description adds no extra parameter semantics, so the baseline 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 states the action ('Connect or update') and resource ('Google account credentials'), and specifies the purpose ('for Google Flow generation'). No other sibling tool deals with account credentials, so it is well-distinguished.
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 when to use the tool (before generating Google Flows), but provides no explicit guidance on prerequisites, exclusions, or alternatives. It lacks clear 'when to use' and 'when not to use' instructions.
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?
There are no annotations provided, so the description carries the full burden of disclosing behavioral traits. The description simply says 'Get detailed information' without mentioning whether the operation is read-only, what happens if the media_id is invalid, what 'detailed information' includes, or any potential side effects. This is a significant gap for a tool with zero 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, front-loaded sentence that clearly communicates the action and resource. There is no wasted wording, and it efficiently conveys the core purpose without 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 is simple (one parameter, no output schema), and the description provides enough information to understand how to invoke it (provide a media_id). However, without an output schema, the description does not clarify what 'detailed information' means or what fields will be returned, leaving some ambiguity about the expected response. It is minimally adequate but has clear 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%: the media_id parameter has a clear description ('Media ID from a previous generation call.'). The tool description adds no additional semantic meaning beyond what the schema already provides, 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's purpose: 'Get detailed information about a specific generated media item.' It uses a specific verb ('Get'), names the resource (detailed information about a media item), and emphasizes 'specific,' distinguishing it from sibling tool list_media which likely lists all media items.
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: you need a media_id from a previous generation call (as stated in the parameter description). However, it does not explicitly state when to use this tool versus alternatives like list_media, nor does it offer any exclusions or alternative recommendations. Usage context is only implied, not explicit.
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 behavioral disclosure. It states the save/download action but does not reveal potential side effects such as file overwriting, folder creation, filename resolution, or return values. This is insufficient transparency for a write 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 a single, front-loaded sentence with no redundant words. It efficiently communicates the core purpose and destination.
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 simple tool with fully documented parameters, the description provides a basic understanding. However, it misses the 'ID' input option and provides no hints about return values or behavior like folder creation or overwrite. Without annotations or an output schema, more context would be expected for completeness.
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 descriptive coverage for all three parameters, so the baseline is 3. The description adds no additional semantic value and actually omits that 'media_url_or_id' can also be a media ID, mentioning only URL. This is a minor gap but does not contradict the schema.
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 ('Save/download'), the resource ('a generated image or video URL'), and the destination ('a local folder on your computer'). This specific verb+resource+destination combination distinguishes it from sibling tools like generate_image, list_media, and get_media_details.
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 'generated image or video URL' implies the tool is used after generation, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
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, but it discloses no behavioral traits such as account requirements, credit consumption, processing time, or return format. The tool name and sibling context suggest it is a generator, but safety/impact details are absent.
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, focused sentence that is front-loaded with the action (Generate) and resource (AI video), then adds model context. No wasted words.
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?
Despite 6 parameters and no output schema, the description provides minimal context. It does not mention the need for a connected account (despite an account parameter), asynchronous nature, or what the response includes. The description is too sparse for a complex generation 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 schema covers all 6 parameters with descriptions (100% coverage), so the description adds no parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
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 states 'Generate an AI video from text' with specific verb and resource, and mentions Google Flow and models. It clearly distinguishes itself from sibling generate_video_from_image by specifying text input.
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 phrase 'from text' clearly indicates the input modality and implies it is for text-to-video, contrasting with image-to-video sibling. However, it does not explicitly name alternatives or state 'when not to use'.
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 behavioral disclosure. It mentions the model (Veo 3.1) but does not explain whether the operation is async, how results are returned, account prerequisites, or error behavior. This is a significant gap for a generation 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, tightly written sentence that front-loads the action, resource, and model. It contains no redundant words and is appropriately sized for the tool's purpose.
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 no output schema, and the description does not explain return values, prerequisites (e.g., Google account connection), or the distinction between providing an image via URL vs base64. The one-sentence description is insufficient for a 6-parameter generation 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 provides descriptions for all 6 parameters (100% coverage), so the baseline is 3. The description does not add parameter-specific details beyond what the schema already states, but the schema itself is sufficient.
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 explicitly states the action ('Animate a static image into an AI video') and the specific resource (Image-to-Video), which clearly distinguishes it from sibling tools like generate_image, generate_video, and upscale_image. It also names the underlying model (Google Veo 3.1), adding specificity.
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 clearly implies the intended use case—when you have a static image to animate—but it does not explicitly contrast with alternatives like generate_video (text-to-video) or mention exclusions. The context is clear but lacks 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.
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. 'Audit' suggests a read-only analysis, which is a useful behavioral signal, but the description does not explicitly confirm that it has no side effects, what it returns, or any permissions required. It implies transparency without fully delivering it.
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 a clear verb-first structure. It is concise, front-loaded, and contains no redundant information, making it easy for an agent to parse quickly.
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 has only one parameter and no output schema, the description adequately explains the audit scope but does not mention what the output or result will be. For a tool with no output schema, this missing detail means the description is not fully complete, though it is acceptable for a simple read-oriented 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 fully describes the only parameter (tool_id) as 'Tool ID or URL to audit,' giving 100% coverage. The description does not add additional meaning to the parameter itself; it just mentions aspects of the audit (capabilities, parameters, etc.). This matches the baseline of 3 for full schema coverage.
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 'Audit' and clearly identifies the resource: 'capabilities, parameters, models, and code logic of a Google Flow custom tool.' This distinguishes it from siblings like run_custom_tool or update_custom_tool, which perform different actions on similar resources.
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 does not explicitly state when to use this tool instead of alternatives (e.g., list_tools or run_custom_tool). The word 'audit' implies an inspection use case, but no concrete context or exclusions are provided, leaving usage guidance to inference.
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 behavioral disclosure. It does not mention any side effects, potential failures, rate limits, or the format of the returned results. The 'efficient' claim is vague and does not provide concrete behavioral details.
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 concise and front-loaded, stating the primary action in the first sentence and adding a comparative benefit in the second. No unnecessary words or repetition.
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's moderate complexity (batch operation, multiple parameters) and lack of annotations or output schema, the description provides only the minimal context. It does not address prerequisites like account setup, error handling for partial batch failures, or output format, leaving gaps for a fully informed invocation.
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 100% coverage with descriptions for all parameters, including the prompts array limit. The description adds no extra meaning beyond what the schema already documents, 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 states the tool's function: generating multiple images in a single batch call. It also distinguishes it from its sibling generate_image by highlighting efficiency, making the purpose unambiguous.
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?
It implies when to use this tool by stating it is 'more efficient than calling generate_image multiple times', which serves as a clear guideline for choosing batch over single generation. However, it does not explicitly mention alternative tools or exclusions.
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 states the operation itself and does not disclose potential side effects, whether the original is modified, authentication requirements, rate limits, or what the return value looks like. This is comparable to the update_drive example rated 2.
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, front-loaded sentence with no redundant content. It communicates the essential purpose and resolution options efficiently.
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 is relatively simple, but without an output schema or annotations, the description does not explain what the tool returns or any operational constraints beyond the schema's plan note for 4K. It provides enough to invoke but lacks broader context, such as the output format or follow-up steps.
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 description does not need to add parameter details. It does not go beyond the schema, which already explains media_id, target_resolution, and account. Baseline 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 states a specific verb ('Upscale'), resource ('an image generated via Google Flow'), and scope ('to high resolution (1K, 2K, 4K)'). It clearly distinguishes from sibling tools like generate_image by focusing on post-generation upscaling.
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 phrase 'generated via Google Flow' clearly indicates the tool is for images already created through that pipeline, providing context on when to use it. However, it does not explicitly mention when not to use it or point to alternatives, so it falls short of a 5.
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 provided, the description carries the full burden. It discloses that the output is for human review and approval, indicating a draft/staging step, and specifies duration and platform constraints. However, it doesn't disclose whether the tool saves files, invokes external models, or has side effects, leaving some behavioral traits opaque.
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 sentence that is front-loaded with the verb and core resource, followed by concise qualifiers (duration, platform, purpose). No wasted words; the description is compact yet information-dense.
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 fully captures the tool's main function and purpose, but given no annotations and no output schema, it could mention what happens after approval or specify what the storyboard keyframes contain (e.g., images vs. text). It's reasonably complete for a script-generation tool, though not exhaustive.
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 four parameters with clear descriptions (100% coverage), so the baseline is 3. The description doesn't add parameter-specific details but aligns with the schema's target_duration_seconds and target_platform. No extra semantic value beyond the schema is provided.
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 'Generate' and clearly identifies the resource as a 'book trailer script and storyboard keyframes' with scope details ('viral 30-45 second social media (TikTok/Reels) cinematic'). It distinguishes from sibling tools like 'generate_storyboard' by combining script and storyboard, and adds the purpose 'for human review and approval'.
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 use for drafting a trailer script and storyboard for human approval, but it does not explicitly contrast with sibling tools like 'generate_storyboard' or 'render_approved_trailer_videos'. No explicit when-to-use vs. alternatives is provided, so guidance is implied rather than direct.
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 provided, the description carries the full burden. It accurately states the core behavior (listing projects) and scopes it to the user's account, but it does not disclose potential pitfalls like pagination, ordering, or authentication requirements. It is minimally sufficient for a simple read-only operation 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?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the verb and object, scoring full marks for conciseness and structure.
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 zero-parameter list tool, the description provides the essential information: what is listed (all Google Flow projects) and for whom (your account). It is reasonably complete given the low complexity, though it could benefit from noting the output shape or any prerequisites.
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 no parameter documentation is needed. Per the rubric, the baseline for zero parameters is 4. The description correctly adds no parameter-related details, as there is nothing to describe.
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 specific verb 'List' and identifies the exact resource ('Google Flow projects') with a clear scope ('on your account'). This fully distinguishes it from sibling tools like 'generate_image' 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool compared to alternatives. There is no mention of prerequisites like connecting a Google account (sibling tool 'connect_google_account') or any exclusions. The usage context is only implied by the verb 'list'.
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 provided, the description carries the full burden of behavioral disclosure. It states it 'checks' status, implying a read-only operation, but it does not explicitly confirm there are no side effects, describe the output format, or address edge cases like what happens if no account is connected or if the connection is invalid. Some behavioral transparency is present but incomplete.
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 lists the key data points without any fluff or redundant phrases. It is well-structured and front-loads the primary action and resource.
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, single-parameter tool with no output schema, the description adequately covers the purpose and likely return data (status, plan, credits, limits). It is slightly incomplete in that it does not specify the default behavior when the optional 'account' parameter is omitted, or describe the format of the returned status, but these are minor gaps for such a straightforward 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 fully describes the one optional parameter ('account') with 'Optional account key or email to check status for.' Since schema description coverage is 100%, the baseline is 3. The description adds no additional meaning about the parameter, so no credit above baseline is warranted.
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 with a specific verb ('Check') and resource ('Google Flow connection status'), and enumerates exactly what it checks: active plan, remaining credits, and daily limits. This distinguishes it from sibling tools like connect_google_account, which establishes the connection rather than checking its 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 context implies this tool is used after connecting a Google account or to monitor usage, and clearly differentiates from connection/setup tools. However, it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like 'must have an active connection' or 'use before generating'.
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 must carry the full burden. It discloses the key behavior of maintaining consistency and references a prerequisite (saved character card), but does not discuss failure modes, permissions, rate limits, or what happens if the character doesn't exist. It adds some context beyond the schema but leaves gaps.
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 sentence that is front-loaded and contains no filler. Every word contributes meaning, efficiently conveying purpose and key benefit.
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 generation tool with a small schema, the description covers the core purpose and prerequisite adequately. However, it lacks explicit comparison to the similar sibling generate_image and does not mention output expectations, but given the schema richness and tool simplicity, it is mostly 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 coverage is 100% with each parameter described, so the baseline is 3. The description adds the concept of consistency and saved character card, which relates to the 'character' parameter, but does not provide additional syntax or format details beyond what the schema already gives. No significant compensation needed.
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 a new image using a saved character card for face/subject consistency. It uses a specific verb (generate), identifies the resource (saved character card), and distinguishes this from generic image generation by mentioning consistency, differentiating it from siblings like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a saved character card and want face/subject consistency. It provides clear context but does not explicitly name alternatives or state when not to use it. The sibling generate_image is an obvious alternative, but no direct comparison is made, so it falls short of a 5.
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 provided, the description carries the full burden of behavioral disclosure. It states the action and outcome (render and download to local folder) but does not mention potential side effects such as overwriting existing files, API costs, required permissions, or failure modes. It is not misleading but lacks depth for a tool that likely mutates filesystem state.
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 conveys the core action and object with zero filler. It earns its place and is 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?
Given the tool's simple two-parameter schema and lack of an output schema, the description is adequately complete for guiding basic selection and invocation. However, more context about prerequisites (e.g., 'approved' status) or pipeline integration could be beneficial, but the current level is sufficient for most agents.
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 100% coverage with descriptions for both parameters (output_folder and approved_shots). The description adds minor semantic context by associating 'local media folder' with output_folder and 'approved storyboard keyframes' with approved_shots, but no additional parameter-level detail beyond the schema.
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: 'Render the final Veo 3.1 video clips from approved storyboard keyframes and download them to your local media folder.' It uses specific verbs ('render', 'download'), identifies the resource (video clips from approved storyboard keyframes), and distinguishes itself from sibling tools like generate_video or generate_storyboard by focusing on the final rendering step from approved keyframes.
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 phrase 'from approved storyboard keyframes' provides clear context for when to use this tool: when you have human-approved storyboard shots and need final rendered videos. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough to guide selection among similar tools like generate_video_from_image.
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/LeoSzn12/google-flow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LeoSzn12/google-flow-mcp)

Score Badge

Copy to your README.md:

[![google-flow-mcp MCP server](https://glama.ai/mcp/servers/LeoSzn12/google-flow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LeoSzn12/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/LeoSzn12/google-flow-mcp'

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