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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false; the description corroborates and enriches this by stating "Saves a new file; the original is kept", which is exactly the consequence an agent needs for a non-destructive mutation. It adds nothing about cost approvals, model selection, or rate limits, so it is not fully rich.

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 short sentences, front-loaded with the core purpose and scoping constraint. "Say what must stay unchanged" slightly overlaps the prompt field's own example in the schema, a minor redundancy, but every sentence otherwise carries weight.

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

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

With an output schema present, return values need no explanation, and the schema documents all 8 parameters at full coverage. The description completes the picture on mutation semantics, preservation of the original, and reference-image behavior; it omits any note on the cost-confirmation threshold, which the schema covers indirectly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning beyond the field docs by explaining what referenceImages are for ("pull elements or style from" / "insert or match") and by prescribing the prompt structure (change + what must stay the same).

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 ("Change an existing image") and enumerates the concrete edit classes it supports (add/remove/replace, restyle, relight, aspect ratio, text fixes). The phrase "existing image" cleanly separates it from the sibling generate_image, which creates rather than modifies.

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 clear context for use (modify an existing image while keeping everything else) and practical guidance ("Say what must stay unchanged", extra reference images for insert/match). It does not explicitly name when not to use it or point to an alternative sibling, so it falls short of the 5 bar.

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?

Adds rich context beyond annotations: asynchronous behavior like generate_video, cost of ~$0.10/second at 720p, the <=10s input limit, and the conversational editing model for Omni clips. This goes well beyond the readOnly/destructive hints.

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 dense sentences, front-loaded with the core action and editing capabilities, followed by input constraints and async/cost details. Efficient, though the parenthetical enumeration and cost clause make it slightly heavy.

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 9-parameter async mutation tool with full schema and an output schema present, the description covers the essential agent-facing facts: purpose, input source, duration limit, async nature, and cost. Nothing material is missing.

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

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

Schema coverage is 100%, so parameters are already fully documented in the schema. The description adds some value by mentioning jobId vs video and the 10s cap, but largely repeats schema content; baseline 3 is appropriate.

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

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

States a specific verb (edit) and resource (existing clip), enumerates the kinds of edits supported, and names the model and siblings it relates to (generate_video). An agent can distinguish it from generate_video, extend_video, and edit_image without opening schemas.

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?

Explains when to use: to change an existing clip while keeping everything else, and clarifies the two input sources (jobId of a finished clip or a video file). It lacks explicit when-not-to-use guidance (e.g. when to prefer extend_video or edit_image), keeping it below 5.

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

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

Annotations already establish readOnly/idempotent/no open-world, so the safety profile is covered. The description adds real behavioral context beyond that: the call compares models only when requested and additionally surfaces remaining budget and whether approval is needed, which is not derivable from the annotation block.

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 leading with the core purpose, then two appended clauses for the optional compare behavior and extra outputs. Every clause carries information, though the semicolon-chained tail is slightly dense.

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

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

With a 100% covered schema, an output schema that documents return values, and annotations covering the safety profile, the description supplies the missing intent layer (multi-media, pre-flight, optional comparison). It is adequate for correct invocation, though it says nothing about output units or error conditions, which is acceptable given the output 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 description coverage is 100% and every parameter (count, model, compare, imageSize, resolution, durationSeconds, etc.) is documented in the schema itself. The description's remark about 'optionally comparing all models' duplicates the existing compare parameter description, so it adds little beyond the structured fields — baseline 3.

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 (estimate) and resource (cost of image/video/speech/music requests) and frames it as a pre-flight step ('before running it'), which implicitly separates it from the generate_*/edit_* siblings. It also names the secondary outputs (remaining budget, approval need), so an agent knows exactly what this tool returns.

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?

'before running it' gives a clear usage context: call this prior to a generation request to preview spend. It does not name explicit alternatives or when-not-to-use conditions (e.g. relation to get_usage or get_config), so it stops short of full 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?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real value beyond them: per-model duration caps, 720p/coherence properties, and that the call is asynchronous like generate_video. It omits cost/threshold behavior, which limits it below a 5.

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

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

Front-loaded with the core action, then dense but earned model-specific detail. The second sentence on async behavior is a compact, useful pointer to generate_video. No filler, though the parenthetical packing is heavy for a single sentence.

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. Given the multi-model complexity, the description covers duration, coherence, resolution, and async behavior well, though it omits cost-confirmation context that the approvedCostUsd parameter hints at.

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 71%, so the schema documents most parameters (jobId, prompt, seed, waitSeconds, approvedCostUsd). The description's model context (10 s omni vs 7 s Veo, last-second vs last-10-seconds context) loosely informs how prompt is interpreted, but it does not clarify the two undocumented parameters (outputName, negativePrompt). Baseline 3 is appropriate.

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

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

The description names a specific verb and resource ("Continue a completed clip from its end") and enumerates model-specific extension limits, so the purpose is immediately clear. However, it never explicitly distinguishes itself from the sibling edit_video, which is the operation an agent is most likely to confuse it with.

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

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

Usage is implied by "completed clip," meaning the input must already exist, and the async note references generate_video as a parallel. But there is no explicit when-to-use vs edit_video/stitch guidance or any when-not condition, leaving routing to inference.

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

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

Annotations declare non-read-only, open-world, non-idempotent behavior, and the description adds material context beyond that: per-1K pricing for each model (~$0.04 / ~$0.15), the fact that every variation in 'count' is separately billed, and the cost-confirmation threshold that triggers approvedCostUsd. That is genuine cost/behavioral disclosure. It does not cover failure modes or quota limits.

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 sentences, no filler, with the core capability front-loaded before the model/cost guidance and the downstream-chaining note. It is dense rather than padded, though the final sentence mixes return-value and routing information that the output schema partly 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 a 9-parameter generative tool with a full output schema and non-trivial cost implications, the description covers capability, cost trade-offs across models, cost-confirmation behavior, and interoperable output URIs. Nothing an agent needs to invoke it correctly is missing, and return-format detail is properly delegated to the output 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 100%, so the baseline is 3. The description still adds meaning the schema lacks: the reference-image limit ('up to 14'), the cost ordering of the three model aliases, and the role of the returned URIs relative to edit_image/generate_video. Payments and billing consequences of 'count' are recast in cost terms rather than just a range.

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 ('Create images from a text prompt') and immediately scopes it with the reference-image capability. It clearly distinguishes itself from edit_image and generate_video, which it names as downstream consumers of the returned URIs, so the agent can separate generation from editing without opening a schema.

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

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

Gives concrete model-selection guidance keyed to use case: nb2 as default, pro for 'densest scenes and final renders', nb2-lite for 'bulk drafts'. It also routes the agent to follow-on tools after generation. It stops short of stating when to prefer this tool over edit_image for an iterative change, so it is clear but not fully exclusive.

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

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

Annotations only declare openWorld/non-idempotent/non-destructive; the description adds the genuinely useful behavioral facts: this is a paid operation ($0.04 vs $0.08), the two models differ in duration and vocal capability, and it returns lyrics/structure text when available. It still does not explain the cost-confirmation threshold tied to approvedCostUsd.

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 compact sentences, front-loaded with the mode/cost tradeoff and followed by control-surface and return information. Every clause carries distinct information with 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?

For a 10-parameter generation tool with an output schema present, the description covers the key decision axes (model, format, cost, prompt controls) without needing to restate return values. Only the approval-threshold mechanics for approvedCostUsd remain unexplained, a minor gap given the schema's own hint.

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

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

Schema description coverage is 100%, so every parameter is already documented (bpm, model, format, images, lyrics, prompt, etc.). The description mostly echoes the prompt's controllable aspects (genre, mood, instruments, tempo, structure) rather than adding syntax or constraints beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Compose music with Lyria') and immediately enumerates the two output modes with their lengths and prices. This clearly separates it from siblings like generate_speech and generate_video without needing to open any schema.

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

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

Gives concrete selection context: clip is the cheap 30-second option, full yields minutes-long songs with vocals/lyrics, and format=wav applies only to full. It does not explicitly route the agent away from siblings (e.g., when to use generate_speech instead), so it stops short of full when/when-not guidance.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true, non-idempotent), so the description's job is to add beyond that — and it does, disclosing cost (~$0.01-0.02/minute) and the default output format, which an agent needs for budgeting. It does not say whether generation is synchronous or job-based, which is the main remaining behavioral gap.

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 short sentences, front-loaded with the core capability, then delivery control, then cost, then use cases. Nothing is redundant and no sentence could be dropped without losing decision-relevant 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 10-parameter, zero-required tool with full schema coverage and an output schema, the description supplies the framing an agent needs: two modes, style control, cost, and target use cases. It leaves the approval-threshold mechanics and sync/async behavior to the schema, a minor but real gap.

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

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

Schema description coverage is 100%, so every parameter already documents itself with examples (voice names, model aliases, BCP-47 codes, inline tags). The description only restates the text-vs-dialogue and style concepts at a high level, adding little beyond the schema — the correct baseline of 3.

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 ('Turn text into natural speech (WAV)') and immediately disambiguates the two operating modes: single voice vs. two-speaker dialogue. That distinction cleanly separates it from siblings like generate_music and generate_video without opening any schema.

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

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

Gives concrete usage contexts ('podcasts, voiceovers, narration and dialogue'), which tells the agent when this is the right tool. It stops short of naming alternatives or exclusions (e.g., when to prefer generate_music for sung/ambient audio), so it is clear context without 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?

Annotations only declare write/openWorld/not-idempotent; the description adds the genuinely load-bearing behaviors: the call is asynchronous and returns a jobId requiring a second call to get_video, and a cost-confirmation threshold gates execution (approvedCostUsd is 'only needed above the confirmation threshold'). It also discloses platform-dependent defaults and that audio is always generated on the Gemini API, which no annotation conveys.

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

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

Front-loads what the tool does and its input modes, then layers model, cost, and async details in decreasing priority with zero filler sentences. It is dense and model-variant heavy in a single block, which slightly taxes scanning, but every sentence carries 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?

For a 15-parameter generative tool with an output schema present, the description covers what remains necessary: input modes, model selection and defaults per platform, pricing path, and the asynchronous follow-up call. Return values are covered by the output schema, so nothing critical is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds decision-level meaning: platform-specific model defaults, the omni 3-10s range and reference-count differences, and the cost-approval gating on approvedCostUsd. Cross-parameter interactions (lastFrame requires image, referenceImages forces 8s) live mainly in the schema, so this is additive rather than complete.

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 precise verb+resource ('Start a video clip with native audio from a text prompt') and immediately enumerates the supported input modes (first frame, first+last frames, reference images). It names the sibling follow-up tool (get_video) and the advisory siblings (estimate_cost, list_models), so an agent can separate this from generate_image, edit_video, and extend_video without opening a schema.

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

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

Gives clear routing context: default model differs by platform (omni on Gemini API, Veo lite on Vertex), estimate_cost should be used to price options, and list_models carries Veo's shutdown date. It also states the async workflow (call get_video after jobId). It stops short of explicit when-not-to-use guidance versus extend_video or edit_video, so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered structurally. The description goes beyond them by describing the informational surface returned (backend selection rationale, policy, warnings) and the diagnostic intent (credentials/missing files), which is genuine extra context for an inspection tool.

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, zero filler. The content enumeration comes first and the use case second, so the agent gets the what before the when.

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

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

With an output schema present, return-value detail is unnecessary in the description, and the zero-parameter, read-only profile needs no further caveats. Content and purpose are both covered, so nothing an agent needs in order to call it correctly is missing.

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

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

The tool takes zero parameters and the schema is a closed empty object, so there is nothing parameter-wise for the description to explain. Baseline 4 applies for a no-parameter tool.

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 ('Show') and resource (configuration) and then enumerates exactly what it reveals: active backend and its selection rationale, output directory, default models, budgets, input-file policy, and warnings. Nothing in the sibling list (media generation, usage, model listing) overlaps with this, so an agent can select it without ambiguity.

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 a concrete situation to reach for it: 'Use it to troubleshoot credentials or missing files.' That is a clear when-to-use signal, but no alternatives are named or excluded (e.g., versus get_usage or list_models for related diagnostics).

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description goes further by disclosing what the report contains, including non-obvious content like budget remaining and running video jobs, and the word 'estimated' signals that the figures are approximations rather than billed amounts.

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

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

A single dense sentence that front-loads the purpose and then lists the report contents without filler. It is appropriately sized, though the trailing list of returned items is somewhat enumeration-heavy for a tool whose output schema already exists.

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

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

With an output schema present, the return shape need not be spelled out, and the description still names the period options and the scope implied by 'this session'. What is missing is any note on data coverage or freshness limits (for example whether it reflects only this server's usage), which would matter for a spend-reporting 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 100%, so both parameters are already fully documented, including the default and max for 'recent'. The description merely restates the period values that the schema enumerates, adding no new syntax, defaults, or interpretation 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?

States a specific verb and resource ('Report estimated spend') and enumerates the dimensions of the report (by model and tool, budget remaining, recent calls, running video jobs). It is clearly distinct from most siblings, but it never draws the boundary against the closest sibling, estimate_cost, which an agent could easily confuse with it.

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's use for inspecting accumulated spend and activity, and the period parameter hints at granularity choices, but there is no explicit when-to-use guidance nor any statement of when another tool (estimate_cost for projections, get_config for settings) should be preferred.

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?

Adds real behavior beyond annotations: the 45s default block, that the tool waits for completion, and that the video is downloaded and returned as a side effect. The idempotency claim aligns with idempotentHint=true, and the download explains readOnlyHint=false. No contradiction, though timeouts/failure behavior is left unstated.

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

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

Two tight sentences with zero filler; the wait-on-completion behavior is front-loaded and the idempotency caveat follows immediately. Every clause 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?

With an output schema present, return values need not be described, yet the description still tells the agent the video is delivered on completion. Blocking duration and idempotency are covered; only timeout/error handling is absent, which is minor for this 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 100%, so jobId's provenance and waitSeconds' default/0 semantics are fully documented in the schema itself. The description mentions the 45s default but adds no syntax or format detail beyond what the schema already gives. Baseline 3 applies.

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

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

Specific verb+resource: 'Check a video job and wait for it', plus what happens on completion (video downloaded and returned). It is clearly distinct from the create/extend/edit siblings in that it only inspects an existing job. It stops short of naming a sibling it could be confused with, but no sibling is a close competitor.

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 polling usage by noting a default wait and stating 'calling again is safe', which tells the agent repeated calls are acceptable. It does not say when to prefer waiting vs. checking once, nor reference generate_video/extend_video/edit_video as the producers of the job handle in narrative form — that context lives only in the schema.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety and statelessness are covered. The description adds that live:true performs an API-key-scoped availability check against the Gemini API, but that is already spelled out in the live parameter's schema text, so the added value beyond structured fields is modest.

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 tightly packed sentences with zero filler, front-loading the primary purpose before the optional-flag behavior. Nothing is repeated and every clause carries distinct 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?

With an output schema present, return values need not be explained, and the description still summarizes them usefully for a zero-required-parameter catalog tool. The remaining gap is routing guidance against sibling discovery/utility tools (get_config, estimate_cost), which the description never addresses.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description goes slightly beyond by naming concrete capability fields returned under detail (aspect ratios, sizes, durations, voices) rather than the schema's generic 'full capabilities'. It still says nothing about mediaType values or includeInactive outside the schema.

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

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

States a specific verb and resource ('List current models per media type') and enumerates the returned content (aliases, status GA/preview/deprecated, prices, usage guide). An agent can tell this is the catalog/discovery tool versus the generate_*/edit_* siblings, though the description never explicitly contrasts it with the closest neighbor, get_config.

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

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

Usage is only implied: an agent infers it should call this to discover available models before generating. The phrases 'detail: true adds...' and 'live: true checks...' describe flag behavior, not when to prefer this tool over estimate_cost, get_config or get_usage, and there are no when-not conditions.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: free/local, saves a large PNG with a default long edge, rejected tiles keep prior pixels, and it returns a preview plus seam crops. It stops short of explaining overwrite behavior for outputName or job lifecycle details.

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 tightly packed sentences with no wasted words: step context and action first, then free/local status, then rejected-tile behavior and output. Every sentence earns its place and the important constraints are 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?

Given rich structured support (100% schema coverage, annotations, output schema) and a clear process description, the definition is complete enough. It explains the main mutation, side effects on rejected tiles, and return previews without needing to repeat return values from the output 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 description coverage is 100%, so all six parameters are already documented in the schema. The description reinforces some meaning (tiles as edited tile outputs, colorMatch as broad color matching, details as 100% crops) but adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb (align, blend, save) and resource (edited tiles into one large PNG), and situates it as 'Upscale step 3' referencing tile_image. An agent can distinguish it from siblings like tile_image or edit_image without opening another schema.

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

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

The phrase 'Upscale step 3' and 'each edited tile from tile_image' clearly imply this should be used after tile_image/edit_image in a workflow. It provides strong context but does not explicitly state when-not to use it or name alternatives by their 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?

Adds real context beyond the annotations: 'Free and local; reports the edit cost' and the important caveat 'Detail is invented, not recovered' — a quality warning the readOnlyHint/destructiveHint flags cannot convey. It stops short of disclosing that crops are written to disk or discussing repeat-call behavior, which matters given idempotentHint=false.

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 action statement, then the pipeline, then the caveat; every sentence carries information. It is dense (long parentheticals and a semicolon chain in sentence two) but not padded — each clause encodes a default, a range, or a routing rule.

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

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

With nine parameters yet only one required, an output schema covering returns, and annotations covering safety, the description supplies exactly the missing layer: first-pass vs refinement-pass semantics, defaults, cost transparency, and the honesty caveat. Nothing an agent needs to invoke it correctly is absent.

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 already 100%, so the 3 baseline applies, but the description goes further by explaining cross-parameter behavior the schema cannot: omitting grid and imageSize picks the cheapest covering plan (one tile up to ~4K, 2x2–4x4 beyond), and that later passes keep their input's size. Only padding/outputName get no extra narrative.

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+scope ('cut an image into crops shaped to the edit model's aspect ratios') and immediately situates itself as step 1 of a three-step pipeline whose other steps are named siblings (edit_image, stitch_tiles). An agent can distinguish it from generate_image or edit_image without opening any schema.

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

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

Explicit sequencing: 'Step 2: edit_image each crop', 'Step 3: stitch_tiles', and 'regions re-render faces or text in a later pass' tells the agent exactly when each mode applies. It also states the fallback behavior when grid and imageSize are omitted, so the agent knows it can call with only the required image.

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