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

With no annotations, the description carries the full behavioral burden and does so well: it discloses non-interactivity, credit-free behavior, that it never starts interactive login, a possible Playwright/headless browser fallback, and a worst-case latency of ~45s. These are meaningful operational details an agent could not infer from the schema.

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

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

The description is front-loaded with the core preflight purpose, followed by behavioral exceptions and timing. The issue reference is minor noise, and the repeated pre-generation call context is slightly redundant, but overall it is efficient.

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

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

For an auth-status probe with an output schema available, the description covers the important operational context: timing, side effects, fallback behavior, and non-interactivity. The main completeness gap is the unexplained `profile` parameter.

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

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

The single optional `profile` parameter has zero schema description coverage, and the description never explains what a profile represents or how it selects a session. An agent can omit it due to the default, but no real semantic guidance is added beyond the schema field name.

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: a non-interactive, credit-free Flow session probe. It distinguishes itself from generation siblings by framing the tool as an auth preflight rather than a generation action.

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 directs the agent to call this BEFORE a generation tool, especially before a long blocking generation call, to fail fast on expired auth. It does not name an alternative auth-checking tool, but the pre-generation timing is clear.

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?

No annotations exist, so the description carries the full burden and it delivers meaningful disclosures: read-only, spends no credits, drives a browser session, and is slower than alternatives. This adds real behavioral context beyond the bare purpose, with no contradictions.

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?

Four sentences, each earning its place: purpose, safety/cost, output-to-usage mapping, and performance caveat. The core purpose is front-loaded and there is zero filler.

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

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

An output schema covers the return shape, and the description covers safety, cost, performance, and how to use the results. The only real gaps are profile parameter semantics and auth prerequisites, which are minor for a simple list tool.

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 0%, so the description must compensate for parameter meaning. It implicitly clarifies the project parameter ('in a project'), but the profile parameter and its default are left entirely to the schema. Partial compensation only.

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

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

The description names a specific verb (List), resource (saved Flow CHARACTER entities), scope (in a project), and what it returns (entity ids). It clearly distinguishes itself from siblings by tying its output to generate tools and explicitly comparing itself to 'the catalog tools'.

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

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

Gives explicit when-to-use guidance ('Call this to discover what you can attach') and explains how to consume the result (id → reference_entities, display_name → @Name mention). The browser-session slowdown hints that catalog tools are preferable when speed matters, though it stops short of naming the exact alternative siblings.

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?

With no annotations provided, the description carries full burden. It states 'Read-only and spends no credits', which is a clear behavioral disclosure. It also explains that ambiguous name results in an error rather than guessing, which is useful error behavior. It mentions 'Drives a browser session', which hints at side effects but is vague. Overall, it discloses key behaviors beyond the schema.

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

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

The description is concise—three sentences with minimal waste. Purpose is front-loaded. The phrase 'Drives a browser session' is slightly vague but not redundant. The structure is efficient for an agent to parse quickly.

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

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

Given the output schema exists, return format isn't needed. However, with 4 parameters and 0% schema coverage, the description omits explanations for 'project' and 'profile', which are essential for invocation. The phrase 'Drives a browser session' is unclear—does it open a browser, require a browser environment, or simply indicate a dependency? This ambiguity could affect correct usage in different environments.

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 0%, so the description must compensate. It explains entity_id and name semantics (by id or exact display name) and notes exactly one is required, but it does not explain 'project' (which is required) or 'profile' (defaulted to 'default'). These remain unexplained, leaving the agent to guess their meaning or values.

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

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

The description clearly states the tool shows one saved Flow CHARACTER entity, specifying selection by id or exact display name. This distinguishes it from sister tools like gflow_character_list (which likely lists multiple) and gflow_character_voices (which deals with voices). The verb 'Show' plus resource 'Flow CHARACTER entity' gives precise purpose.

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 parameter usage guidance: exactly one of entity_id or name is required, and ambiguous names cause an error, prefer id. However, it does not explicitly state when to use this tool versus alternatives like gflow_character_list or when not to use it. The context implies it's for fetching a single entity's details, but no explicit 'use this instead of X' is provided.

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?

With no annotations provided, the description carries the full burden. It discloses that the operation is a static, read-only lookup with no side effects, no network, no browser, and no cost. This is thorough for a simple list tool, and nothing contradicts the 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?

Two sentences with zero filler. The purpose is front-loaded, followed by behavioral context and usage timing. Every word earns its place, and the structure is scannable.

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 parameterless, read-only list tool with an output schema present, the description covers what it does, when to use it, and its cost/behavior. Nothing an agent needs to invoke 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?

The tool has zero parameters, so the schema covers everything trivially (100% coverage). The description adds no parameter details because none are needed. Per the baseline for zero parameters, a score of 4 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?

The description states a specific verb and resource: 'List the preset voices available for a Flow Character's TTS.' This clearly distinguishes it from sibling tools like gflow_character_list or gflow_character_show, which deal with character data rather than TTS voices.

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 instructs when to call it: 'Call it before creating a character to choose a valid voice name.' It also communicates cost/risk ('Static lookup — no network, no browser, no cost'), which guides usage decisions. No alternative tools exist for this purpose, so no exclusion is needed.

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?

With no annotations provided, the description carries the full behavioral disclosure burden and does so remarkably well. It discloses cost ('Spends no credits'), byte verification before writing, image refusal with exit code 11, internal retry behavior, per-profile browser leasing, and concurrent-call failure. This goes far beyond the schema and gives the agent accurate operational expectations.

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

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

The description is dense but every sentence earns its place: purpose, use case, cost, verification, type restriction, retry behavior, and concurrency caveat. It is front-loaded with the primary purpose and keeps critical constraints in a logical order without fluff.

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 tool with an output schema and no annotations, the description covers the essential context: when to retry, what not to do, safety around credits, and failure modes. It falls slightly short only because out_dir and profile semantics are left undefined, which an agent would need to know before invoking successfully.

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 0%, so the description must compensate, but it only meaningfully explains media_id. It does not explain out_dir or profile at all, apart from an indirect reference to 'per-profile lease' that hints at profile semantics without defining it. Two of three parameters remain effectively undocumented.

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

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

The description opens with a specific verb-resource pair: 'Fetch an already-generated VIDEO from Flow by its media ID and write it to disk.' It clearly separates this from generation tools by emphasizing 'already-generated,' and it disambiguates media type by stating that image media IDs are refused.

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 a precise usage scenario: a generation that finished and was billed but whose download failed. It also gives explicit retry guidance: wait and call again, never immediately and never in a tight loop. It doesn't name a sibling alternative explicitly, but the 'already-generated' framing makes the distinction from gflow_generate_video clear.

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?

With no annotations, the description carries the full burden and does so: it discloses that image4 is no longer in Flow's menu, that unported reference types (arbitrary UUIDs, unnamed entity ids) 'fail before submit' and retrying won't help, and that only text-to-image runs on the agent-only composer. It also states the return value ('local file paths to the generated images') and warns origin/composer constraints that determine success.

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 core purpose is front-loaded in the first two sentences, but the remainder is a dense run-on of parentheticals and bare issue numbers (#995, #799) that assume internal context. Most sentences earn their place, but the composer-mode discussion is heavier and more jargon-laden than an agent needs for a routine call.

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 15-parameter, annotation-free generation tool with an output schema, the description covers the highest-risk failure modes and the reference strategy, which is what an agent most needs. It is still silent on profile selection, ui_mode, tools, and instructions, so an agent cannot confidently set those parameters from this text alone.

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 only 7% across 15 parameters, so the description must compensate; it does well for prompt (@Name mentions), count (1-4), model (names plus the 'nano2.1' alias), aspect (enumerated ratios), reference_images, reference_entities/reference_entity_names, and project. It leaves tools, profile, ui_mode, instructions, and output undefined in both schema and description, which is a substantial residual gap.

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

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

Opens with a specific verb+resource ('Generate an image using Google Flow's image models') and states the output cardinality ('Produces 1-4 images from a text prompt'), which cleanly separates it from gflow_generate_video and gflow_upscale_image. The model and aspect enumerations further pin down scope.

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?

Gives concrete routing rules for the two reference mechanisms ('Reference a SAVED named asset via @Name; reference an arbitrary one-off image via reference_images') and states which account/composer configurations support references at all. It stops short of explicitly naming sibling tools to prefer for related tasks (video, upscale, model listing), so it is clear 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?

With no annotations, the description carries full burden. It adds genuinely useful behavior: credit spend risk, abort-before-spend verification, @mention resolution to referenceEntities, and that it returns a local file path. However it omits the long-running blocking nature of generation (documented only in the `wait` schema field), which is the single most important behavioral trait for an agent calling this.

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?

Dense, telegraphic and front-loaded with the core action and modes before detail. The middle is packed into long comma-chained clauses, which is efficient but slightly harder to parse than it could be; every sentence still carries information.

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 19-parameter tool with no annotations, several parameters remain opaque (project identity, frames, resolution, tools), and the blocking/timeout behavior of a default `wait=true` video generation is not surfaced in the description itself. It is adequate to call the tool for the happy path but incomplete for confident use of the full schema.

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 only 5% across 19 parameters. The description compensates for roughly half — mode, aspect, model names, duration, count, prompt @mentions, reference_images, ui_mode — but leaves `project` vs `project_name` vs `profile`, `initial_frame`/`end_frame`, `resolution`, `tools`, and `reference_entities`/`reference_entity_names` unexplained in both places.

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?

Opens with a specific verb and resource: 'Generate a video using Google Flow's Veo model', then enumerates the three generation modes. It is unmistakably distinct from the sibling gflow_generate_image and from the character/instructions tools.

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

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

Gives concrete routing guidance between saved characters (@Name) and one-off ingredient images (reference_images), and explains when ui_mode='classic' is worth setting (pre-submit verification to avoid wasting credits). It never explicitly contrasts with a sibling tool or states when not to use it, 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?

With no annotations, the description carries the full burden and does so well: discloses no credits spent, one browser launch per profile, sequential launching for all_profiles, partial failure visibility, and the important side effect that refresh rewrites saved cookies in a headless browser (slower, revoked sessions need auth login). This is rich behavioral disclosure beyond schemas.

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?

Purpose is front-loaded in the first clause, and the dense parentheticals carry real information. It is long but nearly every clause earns its place; minor density could be trimmed.

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?

An output schema exists so return values needn't be explained, and the description covers the remaining gaps an agent would need: side effects of refresh, failure behavior, and the permanently-null tier fields explained by the source limitation.

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 0%, so the description must compensate, and it does for refresh and all_profiles with concrete semantics and side effects. The 'profile' parameter is only implied ('one saved profile', 'that profile's browser') rather than explicitly defined, keeping it just below a 5.

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 ('Read the current Google Flow credit balance') and even identifies the source of truth ('flow.google.com in that profile's browser'). Clearly distinguishable from all sibling generation/auth tools.

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

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

Gives explicit conditional guidance: 'Set all_profiles=true when choosing an account for generation' and 'Set refresh=true to renew a signed-out session'. It doesn't explicitly route against the nearest sibling (gflow_auth_status) for session handling, so not 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?

With no annotations, the description carries the full behavioral burden bound. It discloses that the operation is persistent, credits-free, and that refs are classified automatically with a side-effect of uploading local image paths. It does not mention permissions, idempotency, or failure modes, but it covers the most non-obvious behaviors.

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

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

The description is two sentences of zero-waste prose. The first sentence front-loads the action and context, and the second uses a compact arrow format to explain ref classification. Every sentence contributes new information.

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

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

The tool is simple, has an output schema, and its required parameter names are largely self-explanatory. The only genuinely obscure parameter behavior, refs, is explained well. Minor gaps such as what exactly 'project' and 'profile' accept prevent a perfect score, but the description is adequate for invoking the tool.

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 0%, so the description must compensate. It thoroughly explains the refs parameter's classification rules, but does not add meaning for project, title, text, enabled, or profile beyond their names and defaults. For a six-parameter tool, one parameter of explanation is not sufficient.

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 clear verb and resource: 'Add a persistent instruction card to a Flow project's Agent-Mode brief.' It also distinguishes itself from media-generation and instruction-management siblings by emphasizing persistence and the credits-free property. An agent can understand exactly what this tool contributes.

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 'Add...' phrasing implies the intended use case, and 'persistent' and 'Agent-Mode brief' give helpful context. However, the description never explicitly names alternatives or conditions such as 'use this instead of gflow_instructions_apply when...'. Selection guidance is left mostly to inference from sibling tool names.

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?

With no annotations, the description carries the full burden and does well: it discloses that unlisted cards are removed, calls the operation destructive, and notes it is credits-free. It does not mention auth requirements or rollback possibility, but the key mutation consequences are clearly surfaced.

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

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

The description is compact, front-loaded with the core full-sync/destructive behavior, and every sentence adds critical information: replacement semantics, card schema, and cost. There is no filler or repetition of schema field names.

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

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

Given the destructive complexity, the description covers the most important operational facts: what gets replaced, what gets deleted, and the card schema. The output schema exists, so the absence of return-value detail is acceptable, but the undocumented 'profile' parameter and lack of any auth note leave minor gaps.

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

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

The input schema provides 0% description coverage, so the description must compensate. It does define the exact card shape ({'title', 'text', 'ref': [...], 'enabled'}), which is valuable. However, the 'profile' parameter is completely unexplained, and 'project' is only implied through the phrase 'Flow project's brief'.

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

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

The description uses a specific verb/resource pairing: 'FULL-SYNC a Flow project's brief' and explicitly states it 'REPLACES all existing instruction cards' with the given set. It clearly differentiates itself from incremental siblings like gflow_instructions_add and gflow_instructions_rm by calling out the destructive, whole-set behavior.

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 communicates that this is for declarative full-sync replacement, which implies the use case but never explicitly says 'use this instead of add/remove for bulk replacement' or warns against using it for single-card edits. The destructive framing provides some routing signal, but no exclusions or alternatives are named.

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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It discloses that the operation is 'Credits-free', which is a behavioral trait not captured elsewhere, and mentions 'reads the live server brief', implying a live data read. However, it doesn't state whether the operation is read-only (though 'List' implies it) or any side effects, which is a gap for a tool with no annotations. This is a modest disclosure but not comprehensive.

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

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

The description is a single concise sentence that conveys the core purpose and a key behavioral hint (credits-free). It's front-loaded with the main action and resource. The only minor issue is that it could be slightly more structured, but it's efficient and not verbose.

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

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

The tool is a simple read/list operation with only two parameters and an output schema (not described). The description covers the main purpose and a key behavioral aspect. However, given the lack of annotations and zero schema coverage, the description should have explained the parameters more thoroughly to be complete. The complexity is low, so this is adequate but not thorough.

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 0%, so the description must compensate for the parameters. The description mentions 'project' in the resource but doesn't explain what 'project' means or what 'profile' does. It also doesn't clarify that 'profile' defaults to 'default' or its purpose. This leaves the agent with minimal parameter understanding, which is inadequate given zero schema coverage.

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

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

The description identifies the specific resource ('Flow project's persistent Agent-Mode instruction cards') and the action ('List'), which is clear and distinct from other instruction-related sibling tools. It also hints at reading the live server brief, adding context. However, it doesn't explicitly name a sibling to differentiate, but the verb-resource combo is specific enough.

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

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

The description implies when to use this tool (when you need to view instruction cards) and mentions it's credits-free, which is a useful usage consideration. However, it doesn't explicitly state when NOT to use it or mention alternatives like gflow_instructions_add or gflow_instructions_apply. The context is clear but lacks explicit routing 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?

With no annotations, the description carries the full burden of behavioral disclosure. 'Remove' implies a destructive mutation, and the description adds that it is credit-free, but it does not disclose irreversibility, permissions, or downstream effects on the project brief. This is a meaningful gap for a deletion-like operation.

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

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

The description is a single, front-loaded sentence with no wasted words. Every clause adds value: what is removed, from where, how it is selected, and the cost implication.

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 destructive tool with no annotations, the description is incomplete. It omits irreversibility, preconditions, and selector-conflict behavior. The presence of an output schema reduces the need to describe return values, but the operational context around removal is still under-specified.

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 0%, so the description must compensate. It adds useful meaning by clarifying that title and card_id are alternative selectors and that exactly one must be used. However, the required project parameter and the profile parameter are not explicitly described, leaving part of the schema semantically uncovered.

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 ('Remove'), a precise resource ('one instruction card from a Flow project's brief'), and the selection mechanism ('by title or card id'). This clearly distinguishes it from sibling tools like instructions_add, instructions_list, and instructions_set_enabled.

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 conveys invocation constraints—exactly one card and one selector ('title or card id'), plus 'Credits-free' as a cost consideration. However, it does not explicitly state when removal should be preferred over alternatives such as set_enabled or toggle_mode, nor does it mention any preconditions.

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?

With no annotations, the description must carry the behavioral burden. It does note 'Credits-free', which is a useful disclosure, and implies a mutation (enable/disable). However, it omits side effects, error handling (e.g., what if no card matches or both title and card_id are given), and permission requirements. This is a mutation tool, so more transparency is expected.

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

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

The description is a single, efficient sentence that front-loads the primary action and key constraint (exactly one). No filler or repetition; it earns its place.

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

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

For a mutation tool with 5 parameters and no annotations, the description is insufficient. It fails to explain what happens if both title and card_id are provided, how to locate a card (e.g., via list tool), or any failure modes. The output schema exists, so return format need not be detailed, but the ambiguous selection semantics and missing parameter context leave the agent uncertain about correct invocation.

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

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

The description clarifies that title and card_id are alternative selection methods and that exactly one is used, which adds meaning beyond the raw schema. However, it does not address profile or project parameters, and schema coverage is 0%, so the description only partially compensates. The 'exactly one' wording may also conflict with the schema, which does not require either field.

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

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

The description clearly states the tool's action: enable or disable one instruction card on a Flow project's brief. It specifies the resource (instruction card), the operation (enable/disable), and the selection method (by title or card id, exactly one). This distinguishes it from siblings like add, rm, and toggle_mode, which have different purposes.

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

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 its siblings. It does not mention alternatives like toggle_mode (which might flip state) or clarify when setting an explicit enabled value is preferable. The phrase 'exactly one' gives selection constraints but no situational advice.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that when off, no cards apply even if individually enabled, and that cards are left untouched, which is critical for understanding the tool's effect. It also mentions 'Credits-free,' indicating no cost, which is valuable behavioral information. This exceeds what would be expected without annotations.

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

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

The description is extremely concise, using two sentences in the first line to state the purpose and effect, followed by a single-word note on credits. Every sentence earns its place: the first sets the action, the second explains the critical behavior, and the third addresses cost. No fluff.

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

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

Given the tool's moderate complexity (3 params, but 2 required), the description is mostly complete for understanding the tool's function and side effects. However, it lacks details on return values (though an output schema exists, it is not shown in the context), and parameter semantics are weak. For an agent to call it correctly, it might need to know the expected format of `project` or the impact of `profile`, which are not described. The output schema's presence helps but the absence of parameter details limits completeness.

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 0%, so the description must compensate for the schema gaps. The description provides no details about the `enabled` parameter's meaning or the `project` parameter (identifier format) or `profile`. It does not explain how the `enabled` boolean affects the master switch beyond 'on or off'. This is a significant gap given the low schema coverage.

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

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

The description clearly states the tool's purpose: toggling a project's brief master switch on or off its effect. It specifies the resource (Flow project's brief master switch) and the verb (toggle), which distinguishes it from sibling tools like gflow_instructions_set_enabled (which enables individual cards) and gflow_instructions_apply (which applies instructions).

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

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

The description implies when to use this tool: when you want to enable or disable all cards at once without modifying them individually. It does not explicitly state when NOT to use it or name alternatives (e.g., use gflow_instructions_set_enabled for individual cards), but the context is clear enough for an agent to infer the primary use case.

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?

With no annotations, the description carries the burden and does well: 'Static catalog... no browser, no spend' tells the agent this is a cheap, side-effect-free lookup with no external session required. It stops short of stating there are no failure modes or that results are cacheable/stable across calls.

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

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

Two tight clauses: purpose and payload first, then the cost/behavior caveat. No filler, and the identity of the tool is front-loaded.

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?

Complete for a zero-arg catalog tool: an output schema exists, yet the description still previews the relevant fields (label, aliases, reference cap, max duration, aspects, tiers), and it flags the browser/spend characteristics that matter for planning.

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?

Zero parameters, so the baseline is 4; the description correctly omits any argument discussion and instead spends its words on the returned 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+resource ('List the image and video models the generate tools accept') and immediately enumerates what each entry contains, which separates it cleanly from gflow_generate_image/gflow_generate_video and from gflow_list_tools.

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

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

Implies the intended context (discovering what the generate tools accept) and rules out browser/spend costs, but never explicitly says 'call this before gflow_generate_image/video to resolve a valid model name,' nor names an alternative catalog tool such as gflow_list_tools.

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?

With no annotations, the description carries the behavioral burden. It discloses the local SQLite data source and the returned fields, but it does not mention that limit/offset control pagination, that the default limit is 50, or what the profile parameter selects, so 'all projects' is potentially overbroad.

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

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

Two sentences with no filler; the key action is front-loaded in the first word. It is concise without being under-specified.

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

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

The output schema covers return values, and this is a simple read-only listing, so the description need not explain return shape. However, pagination and profile semantics are absent, which leaves an agent unsure how to actually retrieve all projects or select a profile.

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 0%, and the description never explains limit, offset, or profile. 'limit' and 'offset' are conventional pagination terms and 'all projects' hints at pagination, but the profile parameter remains completely unexplained, so the description does not compensate for the schema gap.

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

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

The description states a specific verb ('List'), a precise resource ('projects in the local gflow catalog'), and the returned fields (IDs, names, creation dates). This clearly distinguishes it from sibling listing tools such as gflow_list_tools and gflow_character_list.

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 tool's use case is implied by the imperative 'List all projects,' but there is no explicit guidance on when to prefer it over sibling listing tools, nor any exclusions or prerequisites. This is an implied-usage situation rather than explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately states that the tool lists tools and their metadata, which implies a non-destructive read operation. It does not mention authentication or pagination, but for a simple listing operation with an output schema, these are unlikely to be critical gaps. The description is honest and sufficient.

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

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

The description is a single, front-loaded sentence that states the action and the returned fields without any filler. Every word contributes value, and the core purpose is immediately clear.

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

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

Given that the tool has no parameters and an output schema exists (which covers return structure), the description provides all necessary context. It identifies the scope ('gflow prompt tools') and the fields returned, making it fully actionable for an agent. Nothing essential 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?

The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter information, but none is needed. The schema already documents the empty parameter set, and the description does not contradict or complicate it.

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 ('List') and resource ('available gflow prompt tools') and enumerates the fields returned (name, title, description, category). This clearly distinguishes it from sibling list tools like gflow_instructions_list or gflow_character_list, which target different entities.

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

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

The description implies the tool is for discovering available prompt tools, but it does not explicitly contrast it with alternatives or state when not to use it. It relies on the tool name and sibling context for differentiation. There is no direct guidance such as 'Use this to see all tools; for instructions, use gflow_instructions_list.'

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?

With no annotations, the description carries the full disclosure burden and does well: it reveals the Ultra requirement for 4k, Pro/Plus 2k support, that project falls back to the local catalog, the profile/out_dir defaults, and the notable fact that no credits are spent.

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 action, then a tight one-clause-per-parameter exposition and a closing credits note. No sentence is wasted and everything is skimmable.

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?

An output schema exists, so return format need not be explained, and the description covers the required parameter, defaults, tier constraints, and cost. It is complete enough to invoke correctly, with the only gap being no explicit routing to the video sibling.

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 0%, so the description must document all five parameters, and it does: media_id as the image UUID, scale's '2k'/'4k' values with tier constraints, and optional/default behavior for project, out_dir, and profile. This substantially compensates for the empty 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 (Upscale) and resource (platform-generated Flow image) plus the target resolutions and side effect (save locally). It implicitly separates itself from the sibling gflow_upscale_video via 'image', though it never names that sibling explicitly.

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?

No when-to-use or when-not guidance. It never points to gflow_upscale_video for video content or explains preconditions beyond the embedded subscription note, leaving the agent to infer routing from the tool name alone.

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?

With no annotations, the description carries the full burden and does well: it discloses a hard host restriction (flow.google.com only; GFLOW_CLI_FLOW_HOST=labs.google refuses it) and a measured credit cost with a dated observation. It omits overwrite behavior for out_dir and whether the operation blocks or takes time.

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?

Purpose is front-loaded, followed by parameter meanings and then environment/cost constraints. Every sentence carries information, though the dated credit observation is slightly verbose for its value.

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?

An output schema exists, so return values need not be explained; the description covers parameters, host gating, and cost. It leaves error/failure behavior and output-file naming unaddressed, which is a minor gap for a 5-parameter export tool.

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 0%, so the description must compensate, and it documents every one of the 5 parameters: media_id as UUID, the three accepted scale values with meanings, project fallback to the local catalog, out_dir default, and profile default. This is a strong lift over the bare 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 ('Upscale or export a platform-generated Flow video') with the output targets (1080p Full HD / 270p GIF) named inline. An agent can distinguish this from the sibling gflow_upscale_image purely from the description.

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?

Scopes usage to 'platform-generated Flow video' and clarifies optionality of project/out_dir/profile, which tells the agent when defaults apply. It stops short of naming an explicit alternative (e.g. gflow_download_media) or stating when not to use it.

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