Skip to main content
Glama

create_project

Create a NEW Flow project on one of your Google accounts and return its project_id.

Use this to give every one of YOUR OWN clients their own namespace: create a project
per client once, then pass that project_id to generate_image / generate_video so
their results never mix with anyone else's.

account — which Google account creates it (see flow_dashboard / check_credits for the
emails). The project is created under that account, but a project id is a label every
account accepts: generation keeps rotating accounts as before, so results stay grouped
by project_id, not by account. What is still account-bound is media_ids — a follow-up
that reuses one (image_inputs edit-in-place, extend_video, upscale) only works on the
account that produced that particular frame, exactly as today.
name — optional human-readable title, e.g. the client's name.

The returned project is usable for generation IMMEDIATELY. It may not show up in the
Flow web UI's project list (`registered: false` in the result says so) — that only
affects browsing in Google's own interface, not this API: every result comes back as
urls/media_ids in the generation response either way.

Returns {"project_id": ..., "account": ..., "registered": true|false}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
accountYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses substantial behavioral nuance: results are usable immediately, the project may not appear in the web UI (registered: false), account rotation for generation continues, and media_ids remain account-bound. These details are essential for correct agent behavior and are not present in the annotations or 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?

The description is dense but every sentence serves a purpose: purpose, usage guidance, parameter semantics, and edge-case behavior. It is well-organized with clear paragraphs and no repetition or filler. The length is justified by the tool's nuanced behavior, and the most important usage context is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description states the exact return format ({"project_id", "account", "registered"}), while also covering prerequisites, immediate usability, and the UI registration caveat. It is complete enough for an agent to know when to call it, how to call it, and what to expect back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full semantic load. It explains account in depth: which Google account creates it, that project_id is a label accepted by all accounts, and that media_ids are still account-bound. It also explains name as an optional human-readable title, e.g., the client's name. This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Create a NEW Flow project on one of your Google accounts and return its project_id.' It clearly distinguishes this from generation and account-management siblings by tying it to per-client namespaces and explicitly referencing when to use it with generate_image/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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it: 'Use this to give every one of YOUR OWN clients their own namespace: create a project per client once, then pass that project_id to generate_image / generate_video.' It also points to sibling tools for account emails (flow_dashboard / check_credits) and explains the operational distinction between account-bound media_ids and project_id grouping.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.