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

With no annotations provided, the description carries the full behavioral burden. It adds useful context: silent headless background execution and a completion signal in the form of a local MP4 path. Yet it omits failure behavior, timeout semantics, file-overwrite behavior, and any indication of required credentials or credits.

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 short, front-loaded, and has no filler; both sentences carry meaning. However, for a tool with 13 parameters and multiple close siblings, this level of brevity borders on under-specification, which costs one point.

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?

This is a complex, long-running generation tool with no annotations and no schema-level parameter descriptions, so the description must do heavy lifting. It does not explain how to call it correctly, what output_path means, when to use it versus flow_submit_scene or yenflow_generate_scene, or what silent headless mode implies for execution. The output schema mitigates return-value questions but not the missing input and workflow context.

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?

All 12 schema parameters have 0% description coverage, and the description compensates for none of them. It never explains required inputs like prompt or start_frame, nor optional controls like duration, resolution, model, or output_path. The only operational fact mentioned is the MP4 return value, which is not parameter semantics.

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 verb and resource: it generates a single video scene end-to-end and returns the local MP4 path. It distinguishes itself from poll/submit/stitch siblings by claiming end-to-end generation, but it does not differentiate from the near-identical sibling yenflow_generate_scene.

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 'silent headless background mode' implies the tool is meant for unattended single-scene generation, and 'end-to-end' suggests it should be used instead of separate submit/poll steps. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named among the many scene-generation 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, the description carries the full transparency burden and does well: it discloses stateless behavior, zero server-side persistence, validation, credit-cost computation, and a deterministic SHA-256 plan hash. This is meaningful behavioral context beyond the schema.

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

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

Two dense sentences, front-loaded with the core purpose and followed by key behavioral traits. There is no filler or schema repetition.

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 eight underdescribed parameters, no annotations, and a generic output schema, this description is not enough for an agent to construct valid scenes or know valid values for model/resolution/aspect. The high-level plan behavior is clear, but the operational details are 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 0%, so the description needed to explain parameters, but it only generically says it validates scenes and parameters. It adds no meaning for count, model, aspect, duration, background, resolution, or estimated_credits_per_scene.

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 identifies a specific action — planning an I2V video batch — and distinguishes it from submit/generate/poll siblings. It does not explicitly differentiate the closely named yenflow_plan_batch sibling, so it stops short of full sibling differentiation.

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 stateless/zero-persistence language implies this is a planning-only preview step, and returning a plan state suggests it should precede submission tools like flow_submit_scene. However, no explicit when-to-use or when-not-to-use guidance is given.

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; 'Statelessly check' is useful because it indicates a non-mutating read-only poll. However, it does not disclose other behavioral details such as whether calls are non-blocking, auth requirements, or error 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?

A single, front-loaded sentence with no filler; 'Statelessly' appears first and every remaining word contributes to the tool's purpose and identifying parameters.

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 poll tool with an output schema, the description covers purpose, the two key parameters, and statelessness. It still lacks lifecycle context (e.g., call only after a generation has been submitted) and does not explain profile, so an agent gets a functional but not fully rounded picture.

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 meaning to media_id and project_id by saying the check is 'by' those IDs, but it omits any explanation of the profile parameter and gives no format or value guidance.

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 ('check') and resource ('Google Flow completion status of a video generation'), and identifies the key IDs. It is clear, though it does not explicitly differentiate from the near-twin sibling yenflow_poll_scene.

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 polling after a video generation has been created, and 'statelessly' hints at repeatability, but it gives no explicit when-to-use guidance or exclusion such as 'use yenflow_poll_scene for Yenflow.'

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 behavior disclosure. It communicates that the tool invokes ffmpeg and produces a stitched video, which is useful, but it does not disclose critical traits such as whether clips must share codecs/resolutions, whether an existing audio track is replaced, whether output files are overwritten, or whether ffmpeg must be installed on the host machine.

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 redundant words. It identifies the action, inputs, output, an optional behavior, and the underlying technology without wasting space.

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 with only three parameters and has an output schema, which reduces the burden on the description. Still, important operational context is missing: ffmpeg availability, clip compatibility requirements, overwrite behavior, and any differentiation from the sibling stitching 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 carry parameter meaning. It supplies basic semantic mapping: 'clip files' corresponds to clip_paths, 'single unified video' corresponds to output_path, and 'optional audio track' corresponds to audio_path. Beyond that mapping, it adds no constraints, formats, ordering behavior, or path rules, so it only partially compensates for the schema's silence.

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 ('Stitch'), a specific resource (multiple MP4 video clip files), and the result (a single unified video with optional audio). It clearly states what the tool does. However, it does not differentiate from the sibling tool 'yenflow_stitch_video', which appears to have an overlapping purpose, so it loses the top score.

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 no guidance on when to use this tool versus alternatives, especially the similarly named yenflow_stitch_video. There is no mention of prerequisites, exclusions, or routing conditions such as local vs cloud processing.

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 the silent headless execution mode and the immediate return of media_id, which is useful behavioral context. However, it does not disclose what happens on failure, whether the submission is asynchronous, or what the output schema contains beyond media_id. The description is not misleading, but it leaves the agent without knowledge of error behavior or side effects.

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 with no filler. The key behavioral trait (silent headless mode) is front-loaded, and the return value is stated. It is concise, though it could have used the second sentence to explain a parameter or usage condition instead of just restating the return.

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 11 parameters, 0% schema description coverage, no annotations, and a complex async submission workflow, the description is incomplete. It does not explain the relationship between start_frame/end_frame, what 'approved' means, how project_id or plan_sha256 are used, or what the output schema contains beyond media_id. An agent would need to open the schema and guess at semantics for most parameters.

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 11 parameters, but it only mentions 'prompt' and 'start_frame' implicitly via the required fields and 'media_id' as a return value. It does not explain the meaning of model, aspect, profile, approved, duration, end_frame, project_id, resolution, or plan_sha256. The description adds almost no parameter-level meaning beyond what the schema's names and defaults already convey.

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 ('submit'), a resource ('single video scene'), and a target ('Google Flow'), and adds a distinctive execution mode ('silent background headless mode'). It distinguishes from siblings like flow_generate_scene and yenflow_submit_scene by naming the flow_* family and the immediate media_id return, though it doesn't explicitly name a sibling alternative.

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 it: when you need to submit a single scene to Google Flow and get a media_id immediately. It does not explicitly state when not to use it or name alternatives like yenflow_submit_scene or flow_generate_scene. The headless-mode detail hints at a use case (avoiding popups/focus stealing) but no exclusions are given.

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 fully carries the behavioral disclosure burden. It reveals non-interactive behavior, credit-free execution, async queue context, possible Playwright headless browser fallback, and a ~45s worst-case network delay. This is unusually rich and honest disclosure.

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 adding distinct value: core purpose, usage timing and rationale, an important caveat about interactive login, and a performance bound. The information is front-loaded and there is no 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?

The output schema can cover return values, and the description thoroughly covers behavior, timing, and fail-fast usage. However, the single 'profile' parameter is left undocumented, which is a small but real gap for non-default configurations.

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 schema has one optional 'profile' parameter with a default but no description, and the tool description never mentions it. With 0% schema description coverage, the description needed to explain what values profile accepts or what the default means; it does not.

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: a non-interactive, credit-free Flow session probe called before generation tools to fail fast on expired auth. It identifies the resource (Flow session) and the action (auth status probe), and distinguishes it from sibling generation 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?

It explicitly instructs when to call the tool ('BEFORE a generation tool') and explains why (async queue delays auth failure). It also states what it never does ('Never starts an interactive login flow'), giving the agent a clear boundary for when not to rely on it.

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?

No annotations are provided, so the description carries the full behavioral burden and does so thoroughly: image count range (1-4), @AssetName resolution into referenceEntities/referenceImages, and the flow.google.com failure mode where 'UUID/entity references and image4 are not ported to that composer yet and fail before submit; retrying will not clear it.' This discloses failure-prone behavior 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?

Six dense sentences ordered logically: purpose → options (models/aspects) → reference strategies → platform caveat → return value. Every sentence carries distinct actionable content; the flow.google.com caveat is long but high-value, and the only marginal redundancy is the return-format sentence that the output schema already covers.

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 the core use case the description is notably complete — an agent can choose a model, aspect, count, and reference strategy and knows what fails and what comes back. But for a 16-parameter tool with zero schema coverage and no annotations, leaving seed, wait, tools, output, profile, project, ui_mode, instructions, and project_name undocumented is a meaningful gap in the parameter surface.

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?

With schema description coverage at 0%, the description must compensate and does cover the core generation params meaningfully: prompt, count (1-4), model (three named values), aspect (five named values), and reference_images vs reference_entities semantics. Nine parameters (seed, wait, tools, output, profile, project, ui_mode, instructions, project_name) receive no semantic explanation in either the schema or description, leaving an agent guessing on a genuine majority of the parameter surface.

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?

First sentence states a specific verb and resource: 'Generate an image using Google Flow's Imagen model,' and the interaction with sibling tools is unambiguous since gflow_generate_video is the only overlapping sibling. Model and aspect enumerations plus the 'Returns local file paths' statement further pin down exactly what the tool does.

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 rich in-tool guidance: model tradeoffs (nano2 fast, nano-pro balanced, image4 highest quality), reference strategy (@Name for saved assets vs reference_images for one-off images), and the flow.google.com caveat requiring existing projects and local reference files on those accounts. It never explicitly names an alternative tool, but the image-vs-video routing is self-evident from the first line.

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 burden and does a solid job: it explains batch size via count, character resolution into referenceEntities, the pre-submit editor verification that aborts before spending credits, and the fact that the tool returns a local file path. It stops short of describing the wait parameter's blocking behavior or explicit credit consumption, but the coverage is still well above minimal.

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 well-organized, with the core purpose front-loaded and each sentence adding concrete information. The parenthetical-heavy middle sections are somewhat hard to scan, but for an 18-parameter tool the length is justified and there is little wasted text.

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 tool with 18 parameters and no annotations, the description covers the most decision-relevant details: modes, model, aspect, duration, count, character references, ui_mode safety behavior, and return value. It remains incomplete because several optional parameters that could affect invocation, such as wait, project, output, initial_frame, and end_frame, are not addressed even though related sibling tools like gflow_list_projects exist.

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 has 0% description coverage, so the description must compensate, and it adds real meaning for many parameters: mode values, aspect choices, model names, duration units, count as batch size, reference_images as one-off ingredients, and ui_mode behaviors. However, several parameters such as wait, project, project_name, output, initial_frame, end_frame, tools, and reference_entity_names receive no explanation, leaving a noticeable semantic 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 opens with a specific verb and resource: 'Generate a video using Google Flow's Veo model.' It further distinguishes itself by enumerating video-specific modes (t2v, i2v, r2v) and aspects, making it clearly different from the sibling gflow_generate_image tool.

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 provides clear context about mode options, model variants, and how to reference characters vs. pass one-off images, and it explicitly notes that ui_mode 'agentic' is not supported for video. However, it does not explicitly state when to choose this tool over gflow_generate_image or other siblings, so the usage guidance is mostly implied rather than stated as when-to-use/when-not-to-use.

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

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

With no annotations, the description carries the transparency burden and states that the operation is read-only, spends no credits, and surfaces partial profile failures in the result. This is valuable beyond the schema, though it omits potential auth requirements or rate-limit 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?

Three tight sentences: purpose first, then the read-only guarantee, then the key usage tip. Every sentence adds information with no redundancy.

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 read-only tool with two optional parameters and an existing output schema, the description covers purpose, side-effect-free behavior, and a practical usage trigger. Minor gaps like explicit auth expectations do not prevent 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?

Schema description coverage is 0%, so the description must compensate. It explains all_profiles and its use case, but does not elaborate on the profile parameter, its default, or how the two parameters interact beyond the one hint. 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 and resource—'Read the current Google Flow credit balance'—and explicitly scopes it to one saved profile or all profiles. This clearly differentiates it from siblings like gflow_generate_image or gflow_auth_status.

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 provides a concrete usage context: set all_profiles=true when choosing an account for generation. It does not explicitly name alternatives or say when not to use the tool, but the guidance is actionable and distinguishes the parameter's intended 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?

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 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description discloses nothing about side effects, generation behavior, or what the tool returns. It only states it is an alias, which is minimal context.

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 short, but this is under-specification rather than conciseness. A single sentence that merely says 'Alias for flow_generate_scene' does not earn its place because it fails to convey the tool's purpose.

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 13 parameters, no schema descriptions, no annotations, and a complex generation workflow, the description is completely inadequate. An agent cannot correctly select or invoke this tool based on the provided information 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 description coverage is 0%, and the description adds no parameter meaning whatsoever. With 13 parameters and 2 required, the description must compensate for the schema's lack of descriptions, but it provides nothing.

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 is a tautology: 'Alias for flow_generate_scene.' It does not state what the tool does, only that it is an alias for another tool. An agent cannot determine the tool's function without looking up flow_generate_scene.

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 alternatives. The description merely points to flow_generate_scene as the canonical tool, but does not explain when to choose yenflow_generate_scene over flow_generate_scene, yenflow_submit_scene, or other 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 must carry the behavioral burden, but it reveals nothing about side effects, authorization, rate limits, or data flow. The only behavioral claim is that it is an alias, which provides no concrete behavior for an agent to rely on.

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 text is short and syntactically simple, but this is under-specification rather than deliberate conciseness. A single pointer sentence without supporting structure does not adequately describe an 8-parameter tool.

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 8 parameters, one required field, no annotations, and no parameter descriptions, this description is severely incomplete. Although an output schema exists, the absence of purpose, usage, and parameter semantics leaves the agent unable to select or call this tool 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 0%, and the description names none of the eight parameters or their meaning. The agent cannot determine what 'scenes' should contain or how 'model', 'aspect', 'resolution', etc. affect output.

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 only says 'Alias for flow_plan_batch,' which establishes a pointer to another tool rather than stating what the tool does. It gives no verb, resource, or effect, and leaves the agent to inspect the sibling tool for any actual function.

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?

There is no guidance on when to use yenflow_plan_batch versus flow_plan_batch or other siblings. The alias phrase weakly implies interchangeability, but it does not state conditions, prerequisites, or 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.

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

With no annotations and only an alias statement, the description discloses no behavioral traits such as polling, blocking, mutating, authentication needs, or failure cases. An agent cannot anticipate side effects or return behavior from this description alone.

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 very short, but brevity here reflects under-specification rather than effective conciseness. It contains one clause and does not earn its place by conveying meaningful, actionable 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 has required parameters, an output schema, and no annotations, but the description offers none of the needed contextual detail. It at least names the sibling tool flow_poll_scene as a reference, which is a minimal foothold, but it is far from complete for a 3-parameter 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%, and the description adds no meaning to media_id, project_id, or profile. The schema's property names are the only hint, which is insufficient for understanding expected formats or semantics.

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 only states 'Alias for flow_poll_scene,' which essentially restates the tool name rather than explaining what the tool does. It gives no explicit verb-and-resource meaning such as 'poll a scene's generation status.' Without relying on sibling knowledge, an agent cannot determine the tool's actual 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?

No usage guidance is provided. The description does not say when to use yenflow_poll_scene versus flow_poll_scene or any other sibling. It is not misleading, but it provides zero guidance on selection or context.

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 responsibility for disclosing behavior, but it discloses none. It does not indicate whether the operation is read-only or destructive, whether stitching has side effects, what inputs are expected beyond schema names, or what the response contains.

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 short, which is efficient, but this is under-specification rather than genuine conciseness. It front-loads the alias information, but provides no substantive content that helps the agent select or invoke the tool.

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 three parameters, no annotations, and no parameter-level documentation, this description is far from complete. The presence of an output schema cannot compensate for the total absence of purpose and behavioral information needed to call the tool 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 0%, so the description must compensate by explaining the meaning and relationships of clip_paths, output_path, and audio_path. It makes no mention of any parameter, leaving the agent to infer semantics solely from the schema field titles and output 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?

The description merely states that this tool is 'Alias for flow_stitch_video', which identifies a sibling relationship but does not describe what the tool actually does. It relies on the reader already knowing what flow_stitch_video is, and it mostly restates the name/identity in another namespace.

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 given about when to use this tool versus flow_stitch_video or any other sibling. The alias statement implies the tool behaves like flow_stitch_video, but it never states the intended use case, prerequisites, or conditions for choosing this alias.

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 disclose behavioral traits. It says nothing about side effects, requirements, or outcomes. It is completely silent on how the tool behaves when invoked.

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 short, but this is under-specification rather than conciseness. It is not front-loaded with useful content; it simply names an alias with no substantive 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 tool with 11 parameters, no annotations, and an output schema, the description is wholly inadequate. It provides no context about the tool's purpose, inputs, or outputs, making it impossible to use correctly without external knowledge.

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%, and the description does not mention any of the 11 parameters. It provides no semantic help for prompt, start_frame, or any other parameter, leaving the agent to guess from the schema alone.

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 merely says 'Alias for flow_submit_scene,' which does not state what the tool does. It defers entirely to another tool without explaining its function, leaving the agent with no purpose information beyond the name. This is effectively a placeholder.

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 flow_submit_scene or any of the other siblings. The description offers no context, exclusions, or alternative routing.

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