Google Flow Agent MCP Server by useapi.net (third-party)

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing consequences the annotations cannot express: 'approve' incurs a Flow-credit charge at normal price, and 'always' mutates persistent state by switching the project's approval mode to auto. It also documents the ~50s follow-up follow behavior tied to wait.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then decision semantics, then post-answer behavior in a logical order. It is dense and somewhat run-on with nested parentheses, but nearly every clause carries information an agent needs; little is wasted.

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

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

Covers purpose, decision semantics, persistence side effects, cost, and async follow-up behavior for a 3-param mutation tool with no output schema. Return shape isn't described, but the 'chat's next turn' framing plus the wait note sufficiently signals what comes back.

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

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully enriches the bare enum 'approve, always or reject' by explaining the cost, persistence, and side-effect of each value. The wait parameter is also restated in behavioral terms, adding value over the schema's default note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Answer the agent's permission request') and anchors it to concrete context: the pendingApproval surfaced by flow_agent_chat / flow_agent_get_chat, including what the request contains (what it wants to generate and its cost in Flow credits). No sibling tool does this, so an agent can select it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Clearly implies the triggering condition (answering a pending approval) and documents what each decision option does, which is strong contextual guidance. It does not name alternatives or exclusions, but none of the sibling tools compete for this job, so the gap is minor.

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

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

Goes well beyond the annotations: discloses the blocking wait profile (3-40 s to accept, up to ~50 s total), the full status enum returned, the cost model (chatting free, generation costs Flow credits, ask mode prompts first), and the cross-account constraint that references must belong to the chat's account. None of this is derivable from readOnlyHint/openWorldHint/idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then chat-continuation semantics, then reference naming, then timing/return behavior — a sensible ordering with no filler prose. The trailing raw HTTP route list (POST /agent/chats, GET .../stream) is the one part that does not clearly earn its place for an agent caller.

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

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

With no output schema, the description carries the return contract itself (chatId, turn, status, agent text, tool calls, media referenceId+url, pending permission request) and the recovery path via flow_agent_get_chat. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the @referenceImage_N / @character_N naming convention and the chatId-new-chat rule that the schema already documents per property, adding little beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (send a message) and resource (Google Flow's agent), and even scopes what the agent does internally (plans, writes storyboards, generates images/videos). It is clearly distinguishable from siblings like flow_agent_get_chat and flow_agent_list_chats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly states when to omit chatId (start a new chat) vs. supply it (continue, one turn at a time per chat), and names the fallback: when status is running, call flow_agent_get_chat with chatId, wait: true, after: lastEventId. It also points to the lookup tools (flow_upload_image, flow_list_assets, flow_list_voices, flow_list_characters) needed to obtain references.

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

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

Annotations already declare destructiveHint and idempotentHint, but the description goes beyond them by specifying exactly what is destroyed (the chat history) and what survives (generated media stays in the project), plus the timing precondition. This is real behavioral context the agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact clauses front-load the action, destruction semantics, and precondition, ending with the endpoint. Every fragment carries information; nothing is redundant.

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

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

For a single-parameter destructive tool with annotations covering the safety profile and no output schema, the description supplies everything needed: what is deleted, what persists, and the precondition. No meaningful gap remains.

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

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

Only one parameter (chatId) with 100% schema description coverage, so the schema baseline is 3. The REST path DELETE /agent/chats/{chatId} loosely corroborates chatId usage but adds no syntax, format, or ID-source detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (agent chat), and the parenthetical clarifies it also applies to the Flow web app. It is trivially distinguishable from siblings like flow_agent_chat, flow_agent_get_chat, or flow_agent_list_chats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides a clear when-not condition ('Not while a turn runs'), which prevents a common failure mode. However, it names no alternative tool or fallback for a chat that cannot be deleted, so it stops short of full alternative routing.

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

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive/openWorld); the description adds the non-obvious behaviors an agent actually needs: the ~50 s wait ceiling, the possible status values, the pending permission request and last-error fields, media url refresh, and the lastEventId cursor contract for resuming.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose in the first five words, then branches cleanly into wait and non-wait behavior. The single dense paragraph repeats a bit of what the schema already documents (limit, media), which keeps it short of a 5.

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

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

With no output schema and five parameters, the description carries the return-shape burden well: it enumerates title, status, pending permission request, last error, turns and media status/urls, plus the underlying endpoints. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the field docs: it ties 'after' to a lastEventId produced by an earlier flow_agent_chat / flow_agent_get_chat call, and explains that wait governs whether the other params apply. It adds genuine usage semantics rather than restating types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Read a Flow agent chat" is a specific verb+resource, and the description immediately differentiates this read tool from the sibling write path (flow_agent_chat) and the list path (flow_agent_list_chats) by spelling out the per-chat return payload. An agent knows exactly what it will get back without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives explicit operational guidance for the two modes: wait:true to follow a live turn and fetch 'the rest of a turn still running', and the default no-wait read. What is missing is sibling routing — it never says to prefer this over flow_agent_list_chats or flow_agent_chat in a given situation.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low; the description goes beyond them by disclosing the payload contents and decoding the 'ask' vs 'auto' approval-mode semantics, which the agent cannot get from annotations. It stops short of describing error or empty-settings behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with verb and resource, single dense sentence with every clause carrying information, plus the endpoint. Slightly heavy nesting of the approval-mode gloss, but nothing is wasted.

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

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

With no output schema, the description carries the burden of describing the response and does so by enumerating every returned field group (approval mode, instructions, models, aspect ratio, count). Nothing an agent needs to call and interpret this read is missing.

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

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

Schema coverage is 100% and both parameters are already documented there, including the projectId vs default-project distinction. The description's parenthetical ('or the projectId given') only mildly reinforces the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (read) plus specific resource (the agent settings of the account's agent project or a given projectId), and it enumerates exactly which settings are returned. An agent can distinguish it at a glance from the write sibling flow_agent_update_settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context: read the account's default agent project, or supply projectId to target another project. It does not explicitly name flow_agent_update_settings as the mutation alternative or state exclusions, 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds useful context by naming the returned fields and the GET endpoint, but says nothing about pagination, result limits, or auth requirements beyond the implicit token.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense sentence that front-loads the action, then the scope, then the returned payload, ending with the endpoint. No filler and nothing redundant.

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

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

With no output schema, the description compensates well by naming the fields returned (chatId, title, created, updated, running-turn status). What remains missing is pagination/limit behavior and relationship to the other chat siblings, but for a zero-required-parameter read tool this is close to complete.

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

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

Schema description coverage is 100%, so both email and projectId are already documented in the schema, including the optional-when-single-account nuance. The description's 'in its agent project, or the projectId given' restates the projectId semantics without adding syntax or format detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the agent chats of a Google Flow account') and enumerates the returned fields (chatId, title, created, updated, running turn). The list-vs-get-vs-delete distinction from siblings like flow_agent_get_chat is clear from the name and description, though no sibling is explicitly named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied by the verb 'List'; there is no explicit statement of when to call this versus flow_agent_get_chat or flow_agent_chat, nor any prerequisites. The one guidance-like clause ('in its agent project, or the projectId given') describes scoping rather than when-to-use.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and repeatability profile is covered. The description adds the concurrency restriction (no rename during an active turn) and notes the change surfaces in the Flow web app, which is useful extra context but leaves failure behavior and permission requirements unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short fragments, front-loaded with the core action and free of filler. The PATCH path is arguably redundant metadata but costs little.

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

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

For a simple two-parameter mutation with no output schema, the description covers the action, a timing constraint, and the idempotent nature (reinforced by annotations). Only the success/error outcome is left implicit, which is a minor gap.

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

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

Schema description coverage is 100% and both parameters are documented in the schema (title with a 200-char limit, chatId). The description adds nothing about parameter meaning beyond the PATCH path template, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Rename an agent chat'), which is unambiguous and distinct from siblings like get_chat, delete_chat, and update_settings. It does not explicitly differentiate itself from those siblings, but the rename action is unique enough that confusion is unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The phrase 'Not while a turn runs' supplies one real when-not condition, which is genuinely useful timing guidance. However, it names no alternatives and gives no positive context for when renaming is the right call versus deleting or re-creating a chat.

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

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

The description adds useful behavior: approval=auto can spend Flow credits, instructions replaces the whole list, the settings are returned as saved, and the endpoint is PUT /agent/settings. However, 'instructions replaces the whole list' is a destructive replacement behavior that contradicts destructiveHint=false, which promises only additive updates. This is an annotation contradiction, so the score is 1 per the rubric.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single compact paragraph that front-loads the purpose and then adds only concrete operational facts: minimum payload, replacement semantics, return behavior, and endpoint. There is no redundant restatement of the title or schema.

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

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

For a complex nested-object mutation tool, the description covers targeting, minimum payload, replacement semantics, return value, endpoint, and credit side effects. The absence of an output schema is partly offset by 'Returns the settings as saved,' but it does not explain error behavior or whether unspecified settings are preserved.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds non-schema meaning by imposing the 'send at least one of' constraint and by warning that approval=auto spends Flow credits, which the schema does not mention.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Change the agent settings.' It also scopes the target precisely (the account's agent project or a supplied projectId) and explains auto-creation, making it clearly distinct from flow_agent_get_settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explicitly tells the caller to send at least one of approval, instructions, imageDefaults, or videoDefaults, and clarifies the default project target versus projectId. It does not explicitly name flow_agent_get_settings as the read alternative or state when not to use this tool, so it falls short of full when/when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context and it does: default page size of 50, ceiling of 200, and the notable 'a large project can take 20 s or more to read' latency warning. It stops short of describing pagination or error behavior, but the added operational context is real.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads purpose and hits scoping, defaults, limits, latency and endpoint in order. Nothing is wasted, though the middle clauses about project scoping are slightly packed and could be broken out.

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

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

With no output schema, the description still conveys the shape of results (newest first, reference id, upload flag) and the default/limit behavior. Minor omissions remain around pagination beyond the limit and ordering guarantees across projects, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: the concrete parameter syntax for downstream use (referenceImage_N / referenceVideo_1), which projectId to pick in practice, and what 'uploadsOnly' excludes. This is value beyond the field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the images and videos in a Google Flow project'), specifies ordering ('newest first'), and describes what each item carries (reference id, upload flag). It is clearly distinguishable from siblings like flow_list_characters, flow_list_voices and flow_upload_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly tells the agent which projectId to pass and when: default main project for API generations, or the id from flow_agent_get_settings for agent-made media. It also explains the uploads-only scope and how returned reference ids feed into flow_agent_chat, so the routing decision is fully specified.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the description only needs to add context. It does so by disclosing the underlying GET /characters endpoint and the shape of each returned record, which is valuable given there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense but front-loaded sentence covering purpose, return fields, and downstream usage, followed by the endpoint. Every clause carries information and nothing is padding.

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

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

For a read-only list call with one optional parameter and no output schema, the description supplies the returned field set and the identifier-chaining convention, which is what an agent needs. Account selection is deferred to the schema, leaving only minor gaps like ordering or pagination.

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

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

Schema description coverage is 100% and the single optional 'email' parameter is fully documented there, so the baseline is 3. The description implies the tool operates against one Flow account but adds no fallback or multi-account syntax detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the characters saved on a Google Flow account') and goes further by enumerating what each entry contains (reference id, name, images, voice). The resource noun 'characters' cleanly separates it from sibling list tools such as flow_list_voices and flow_list_assets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly tells the agent how to consume the result: pass the id as character_N to flow_agent_chat and reference it as @character_N, which routes the agent to the correct sibling. It stops short of stating when not to use this tool or the prerequisite that identifiers come from this call, so it is strong context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the HTTP verb+path (GET /voices), the accepted source filter values, and the identifier convention (referenceAudio_N, referenced as @referenceAudio_N) that governs how results must be consumed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the core action and keeps the integration detail attached. The referenceAudio_N/@referenceAudio_N naming is stated twice in close proximity, which is slightly redundant but not wasteful.

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

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

With no output schema, the description still conveys what is returned (two voice categories), how to filter them, and how the resulting identifiers feed flow_agent_chat. Return shape/pagination is omitted, but for a simple read-only list tool the coverage is sufficient.

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

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

Schema description coverage is 100%, so both parameters are already documented with their enum and optionality. The description's 'source: system or user only' largely restates the schema, and email filtering semantics are not expanded upon, so it sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('List the voices of a Google Flow account') and splits the resource into its two meaningful sub-kinds (built-in vs. custom), which is the distinction an agent actually needs. It does not explicitly position itself against flow_list_assets/flow_list_characters, but naming flow_agent_chat as the consumer makes the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Tells the agent the key downstream condition: pass the name for built-in voices and the voice reference id for custom ones when using flow_agent_chat. It gives clear context for source values but offers no explicit when-not-to-use or sibling call-out.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive, open-world write. The description adds genuinely new traits beyond that: uploads persist on the Google account until deleted, a 20 MB size ceiling, and the accepted mime types. It does not discuss auth requirements or failure modes, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads the operation, then constraints, then the downstream handoff. Every clause carries information; nothing is padding.

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

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

With no output schema, the description compensates by describing the return value (the reference id) and how to use it. Combined with source modes, size/type limits, account scoping and asset lifetime, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema: it clarifies the url-vs-contentBase64 tradeoff (base64 only for small files), states the 20 MB limit, and ties the email parameter to the chat's account by explaining a reference only works there.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Upload) plus resource (your own JPEG/PNG/WebP image) and target system (a Google Flow account), with source modes spelled out. It is clearly distinguishable from siblings like flow_list_assets or flow_agent_chat, and even names the endpoint POST /assets/{email}.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear context for the two input modes (public https url vs contentBase64 for small files, 20 MB cap) and explicitly routes the agent downstream: pass the returned id as referenceImage_N to flow_agent_chat, named @referenceImage_N. What is missing is exclusion guidance — it never says when not to use this tool or which alternative to prefer.

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