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

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

Goes well beyond the annotations: it discloses that a NEW avatar is always created and the original is preserved (useful against idempotentHint=false and destructiveHint=false), that the response returns avatarId and picture, that each generated picture consumes one image from the plan allowance but is never refused on a plan without one, that prominent-person photos are rejected with 422, and that runs take ~10-60 s on POST /avatars.

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

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

Dense, front-loaded, and every clause carries information (billing, refusals, latency, return values). It is packed into a single run-on paragraph heavy with parentheses, which makes it slightly harder to scan than a short structured list, but there is essentially no 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 12-parameter, non-idempotent creation tool with no output schema, it covers the essentials an agent needs: valid start-point combinations, what is returned, cost implications, failure modes (422), and expected latency.

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 schema carries the baseline; the description still adds cross-parameter meaning the schema does not, linking voice to vids_list_voices, noting the logo is applied when refining the picture ('Say where in refine'), and clarifying 'refine and logo change that picture' applies after the start point.

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 precise verb and resource ('Make a voiced avatar = a person's picture plus a voice') and immediately scopes it to its consumers (vids_create_avatar_video, vids_create_video avatar_1..3), so it is distinguishable from vids_create_image and vids_create_avatar_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?

Explicitly gives the three mutually exclusive starting points (appearance / image / avatar) with the condition for each and the sources of the values (vids_upload_asset, vids_create_image, vids_list_avatars, vids_list_voices), plus the rule that each start produces a new avatar rather than modifying one. It tells the agent both what to supply and which alternative applies.

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

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

Goes well beyond the annotations by disclosing billing behavior (consumes 1 AI avatar video from the monthly allowance, and is still charged when Google's safety check refuses the clip), asynchronous latency (1-2.5 minutes), and the returned jobid. These are exactly the non-obvious traits an agent cannot infer from readOnlyHint=false and openWorldHint=true.

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 critical facts (who speaks, resolution, duration, cost, latency, endpoint) are front-loaded and every clause carries information. It is dense with stacked parentheticals, which slightly hurts scannability, but almost nothing is wasted.

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

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

With no output schema, the description correctly compensates by explaining that the call returns a jobid rather than a finished video, and how long to expect. Cost, duration, resolution, script limits, and the failure/charging case are all covered, so an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds real value on top: the script field accepts voice tags like [whisper] or [short pause], and the avatar runs on the account owning that avatarId (cross-referencing vids_list_avatars). It does not add syntax detail for the avatarId itself, so it stops short of a 5.

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

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

States a concrete verb and resource (create a talking-head avatar video from a script) with explicit scope: 1280x720 landscape only, up to 30 s, script up to 400 characters. It directly distinguishes itself from the sibling vids_create_video ('3-15 s scenes with action' vs 'the avatar just speaks to camera'), so an agent can route between them without opening either 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?

Names the alternative (vids_create_video) and the condition that selects it (action scenes vs. one avatar speaking a script), and explains the follow-up path by stating it returns a jobid for vids_get_job. The agent knows both when to pick this tool and what to do next.

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 side-effect profile (write, open-world, non-idempotent), and the description goes well beyond them by disclosing the billing consequence, approximate latency, output format, and the concrete handle it returns for chaining. Nothing contradicts the annotations and no relevant trait is hidden.

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: purpose first, then output/handle, then cost, latency, and endpoint. Every clause carries actionable information 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?

With no output schema, the description correctly explains the return (a visible image plus its mediaId) and how to use it downstream. Together with the annotations and fully documented schema, an agent has everything needed to invoke this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by mapping the aspectRatio enum to actual pixel dimensions (1376x768 / 1024x1024 / 768x1376) and by quantifying the style set. It slightly misstates the style count (7 entries in the enum include "none", the default), but otherwise adds meaning over 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 ("Generate one JPEG ... from a prompt") and pins down scope with the three supported resolutions and existence of styles. It also distinguishes itself from siblings by naming the downstream artifacts (startImage / referenceImage_N / avatar picture), which separates it from vids_create_avatar and vids_create_video.

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 when this is the right call (you need a generated still to feed a video or avatar) and warns of the cost (one image from the monthly allowance) and latency (~10 s). It never names an alternative for the case where the user already has an image (e.g. vids_upload_asset), so exclusions are absent.

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

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

The description adds materially beyond the annotations: it discloses cost (1 from the monthly Gemini allowance), that refused scripts cost nothing, latency (a few seconds), the return value (audio mediaId retrievable via vids_get_media), and that voice tags like [whisper] are spoken rather than read. These facts align with and enrich the non-idempotent, non-destructive, open-world annotations rather than repeating them.

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?

It is dense and nearly every clause carries information: format, use case, limits, tag handling, cost, latency, and return shape. The opening noun-phrase sentence is slightly awkward grammatically, and the usage rationale is embedded mid-sentence rather than front-loaded, but 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?

For a three-parameter creation tool with no output schema, the description covers what an agent needs: what it produces, the format, cost implications, failure cost, latency, and how to fetch the result. Nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the script cap of 2500 characters and the semantics of inline voice tags are behavioral details the schema's 'The text to speak.' does not convey. It also reinforces that voice must come from vids_list_voices. The email parameter's fallback behavior is left entirely to 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?

The description names a concrete resource and output: a WAV file (24 kHz mono) voiced from a script, using a voice from vids_list_voices. It clearly separates this from the video-producing siblings by framing the audio as a preview ('before making a talking avatar video') or a standalone asset. The only weakness is that the lead is a noun phrase rather than an explicit verb, so the action must be inferred from the title.

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

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

It gives clear usage contexts: auditioning a voice or script before a talking avatar video, or reusing the audio elsewhere. It also names the prerequisite sibling vids_list_voices for the voice parameter. It stops short of stating when not to use it versus vids_create_avatar_video or vids_create_video, leaving that inference to the reader.

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?

Beyond the annotations (non-read-only, open-world, non-idempotent), the description discloses the billing model (consumes the clip's seconds from the account's monthly allowance), latency (~50 s wait), and the async job pattern returning a jobid consumed by vids_get_job. Those are the operational facts an agent needs before committing to an expensive, slow, non-idempotent call.

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

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

One tight paragraph, front-loaded with the core capability and mode list before cost and job mechanics. It is dense with parentheticals ("(referenceImage_1..3 images and avatar_1..3 voiced avatars)") which slightly hurts scanability, and the trailing "POST /videos" is an implementation detail of marginal value to an agent.

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 12-parameter, no-output-schema creation tool, the description covers the mode matrix, prompt syntax, cost, latency, and what is returned (a jobid for vids_get_job). Since there is no output schema, that return-value sentence is essential and it is present; the only soft spot is the ambiguous "waits up to ~50 s" failure path.

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 schema already documents every parameter and the baseline is 3. The description adds real meaning on top: the @referenceImage_N/@avatar_N prompt marker convention, the fact that avatar lines are written as prompt text, and the grouping of referenceImage_1..3 plus avatar_1..3 into a single mutually-exclusive "references" mode.

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 gives a specific verb and resource ("Generate a 3-15 s clip with sound and speech") and enumerates its three input modes: text-only, a startImage, or up to three references (images and voiced avatars). That makes the capability clear, but it never names the sibling it competes with (vids_create_avatar_video, vids_extend_video, vids_edit_video), so the agent must infer the boundary itself.

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

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

It gives concrete how-to guidance: name references as @referenceImage_1 or @avatar_1 in the prompt, and write an avatar's spoken lines into the prompt, plus the mode structure (startImage XOR references). What is missing is any exclusion or alternative routing — nothing tells the agent when to pick this over vids_create_avatar_video or vids_extend_video.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds account scoping ("its account's Vids document") and the HTTP endpoint, which is some useful context, but it does not explain irreversibility, side effects on videos, or auth requirements beyond what annotations provide.

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 short sentences, front-loaded with the purpose, with no filler. The second sentence ("DELETE /avatars/{avatarId}") is arguably redundant with the tool name but still specifies the exact API operation, so it earns its place with only minor 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 single-parameter destructive delete with full annotations and no output schema, the description covers the purpose, account scope, and endpoint. It is adequate, though it could note dependencies such as whether the avatar is removed from existing videos.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema's only parameter description is the tautological "The avatarId," so the description adds no meaningful semantics beyond restating the parameter in the endpoint path.

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 ("Remove") and resource ("avatar"), making it clearly distinct from siblings like vids_create_avatar and vids_list_avatars. However, it does not explicitly name or contrast with any sibling tool, so it falls short of the top score reserved for descriptions that both identify the operation and route the agent away from alternatives.

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 this tool versus alternatives, no conditions or prerequisites, and no exclusions. The deletion use case is implied only by the verb, which is the minimum implied usage rather than explicit 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 readOnly=false, idempotent=false, openWorld=true and destructive=false, so the safety profile is covered. The description adds genuinely new behavior: the operation is asynchronous (a job), and the output is truncated to at most 15 seconds taken from the start of the clip. It does not mention cost, latency, or whether the source clip is preserved.

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 clauses plus an endpoint reference, with the core action and the 15-second truncation front-loaded. No filler or redundant restatement of the title.

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

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

With no output schema, the description carries the burden of describing the return, and it does so by indicating a job is produced and that the resulting clip is capped at 15 seconds from the start. It could be more explicit that a job id is returned and must be polled, but the essentials for correct invocation are present.

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 five parameters are already documented, including the 3-15 second duration bound and the default-inherits-from-source behavior for resolution and aspectRatio. The description's 'up to 15 s of it, from the start' reinforces the duration semantics but adds little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Change a generated clip with a prompt') and enumerates the kinds of edits (colours, objects, style). It also distinguishes itself from vids_create_video by noting it is 'A job, like vids_create_video', though it never explicitly contrasts with vids_extend_video or vids_upscale_video.

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 'A job, like vids_create_video' implies the async job pattern and that the caller should poll vids_get_job, and 'from the start' hints at a scope limit. However, there is no explicit when-to-use guidance versus the closely related vids_extend_video or vids_upscale_video siblings, leaving the choice 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 only flag non-read-only, open-world, non-idempotent, non-destructive. The description adds real behavior: this is an asynchronous job ('A job, like vids_create_video'), it returns the entire longer clip rather than just the delta, and 'uses only the added seconds' hints at how consumption/billing is scoped. It stops short of saying how to poll for completion or what the job result looks like.

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 with the size constraint front-loaded and no filler; the endpoint hint at the end is low value but harmless. Minor compression ('3-10 s', 'uses only the added seconds') leaves a little ambiguity about whether that phrase refers to billing, sampling, or prompt scope.

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 five-parameter async mutation with no output schema, the description covers the important pieces: job semantics, what is returned, the length ceiling, account scoping, and iteration. It omits how the caller retrieves the result, though the schema's mediaId text points to vids_get_job, which partially compensates.

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 all five parameters (prompt, mediaId, duration, resolution, aspectRatio) are already documented, including defaults and enums. The description adds only the derived constraint that the source clip can be up to 24 s and the total can reach ~34 s, which is useful context but not parameter-level semantics beyond the schema; 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?

The description gives a specific verb and resource ('Add 3-10 s to a generated clip'), plus concrete scope limits (source up to 24 s, output at most ~34 s). It does not explicitly contrast with the closest siblings, vids_edit_video and vids_upscale_video, so an agent must infer which one to pick when the intent is 'change an existing video'.

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 states the key operating context: run on the same account, and 'Call it again on the result to go longer, up to that limit,' which tells the agent how to chain calls for longer output. It gives no explicit when-not guidance versus vids_edit_video or vids_create_video as a fresh generation alternative.

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description usefully adds that the check is 'live at Google' — i.e. a real-time remote fetch — and what data the response carries. It does not describe failure behavior for an unknown or non-existent email, nor whether quotas are per-account or shared.

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

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

Purpose and result contents are front-loaded in a single efficient sentence, with the HTTP endpoint appended as a compact technical anchor. The parentheticals (avatarVideo, speech) add mapping value rather than waste, though the sentence is somewhat 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?

For a one-parameter read tool with no output schema and annotations covering the safety profile, the description is close to sufficient: it tells the agent what is checked and what the response reports. The main gap is the error/not-found case, which matters for an openWorld live lookup.

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

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

Only one parameter, and the schema already documents it at 100% coverage as 'The account email.' The description adds the routing detail GET /accounts/{email}, clarifying the email is the path identifier, but adds no further format or validation meaning.

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 ('Check one account live at Google') and enumerates exactly what is reported: sign-in status and remaining monthly quota for video seconds, images, music, avatar videos and Gemini/speech uses. The word 'one' implicitly separates it from vids_list_accounts, though no sibling is named explicitly.

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

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

Usage is only implied: check a single account when you need live sign-in state or remaining quota. There is no explicit guidance on when to prefer this over vids_list_accounts (many accounts) or vids_update_account (mutating the account), and no stated preconditions for a known/unknown email.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description still adds real context the annotations do not: the ~50 s ceiling on wait:true, the 7-day job retention window, and the shape of the completed result including the image-block variant. It does not describe behavior for expired or failed jobs, which keeps it from a 5.

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

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

A single tight block with no filler; the result payload is front-loaded before the wait flag and retention note. The opening is a bare noun phrase rather than a verb clause, which slightly delays the 'this fetches a job' reading, but nothing is redundant.

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

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

With no output schema, the description correctly takes on the burden of describing return values (mediaId, size, duration, download URL, image block) and adds retention and timeout facts an agent needs to call it correctly. Only error/expiry handling is left implicit.

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%, with the wait parameter already documented as 'Wait up to ~50 s for the job to finish.' The description repeats that same wait semantics and adds no format, default, or fallback guidance for jobid. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 the resource precisely (a job of any of the four creation types) and states that it returns status plus, once completed, the result fields. The trailing "GET /jobs/{jobid}" disambiguates it as a single-job fetch, implicitly separating it from vids_list_jobs. It falls short of a 5 only because it never explicitly contrasts itself with the list or media siblings.

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 rather than stated: the presence of a wait flag and the emphasis on 'once completed' signal that this is the polling tool for a job returned by a create call. There is no explicit 'use this instead of vids_list_jobs when you already have a jobid' and no guidance on what to do if a job has aged out.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive, open-world), the description discloses the return shape per media type — images come back viewable, video/wav only as type, size and URL — and the key operational trait that Google-hosted files are temporary and an expired one answers 404. That 404/expiry detail is exactly the behavior an agent cannot infer from annotations and needs in order to handle failures correctly.

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?

It is a single front-loaded sentence that opens with the action and ends with the endpoint, with no padding or restatement of the title. The clause stacking around return types is a bit dense but each clause carries distinct information, so nothing is wasted.

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

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

With no output schema, the description carries the burden of describing return values and does so per media type, and it covers the failure mode (expired file = 404) for a one-parameter read tool. Only minor gaps remain, such as whether the returned URL itself is time-limited or whether any auth scope applies.

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 parameter is already documented, but the description adds real meaning by stating where a valid mediaId comes from (a job result or an avatar's previewMediaId) rather than the generic 'A video, image or audio (speech) mediaId' in the schema. That provenance guidance is genuine added value on top of the baseline.

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

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

States a specific verb and resource ('Check a mediaId ... and get its download URL') plus the underlying endpoint GET /media/{mediaId}, and it lists the two places a mediaId originates (a job result or an avatar's previewMediaId). That distinguishes it clearly from the sibling creation/list tools, which never return a single media artifact.

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 tells the agent when to reach for this tool by naming the upstream sources of a mediaId (job result, avatar previewMediaId), which implicitly routes the agent through vids_get_job or vids_list_avatars first. It stops short of naming alternatives explicitly or saying when not to use it, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavior: 'No call to Google' (serves cached/stored state despite openWorldHint) plus the exact fields returned (health, maxJobs, monthly limits, avatars-only flag), which clarifies what the agent will observe.

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

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

One sentence, front-loaded with the resource and scope, with the return contents enumerated compactly after the colon and the endpoint appended. No redundant or filler clauses.

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

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

With no parameters and no output schema, the description carries the return-shape burden and does so by naming the meaningful fields an agent needs (health, maxJobs, monthly video/image limits, avatars-only). Combined with the annotation coverage on safety, 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing the description needs to disambiguate. It instead spends its budget on return contents, which is the right trade for a no-arg 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 ('List') and resource ('Google accounts added to this useapi.net API token for Google Vids'), and the singular sibling vids_get_account is naturally contrasted by the plural scope. An agent can tell immediately this returns the full account collection rather than one account.

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 the word 'List' and by the contrast with vids_get_account, but the description never says explicitly when to call this versus the singular getter, nor when the cached stored view is preferred over a fresh Google lookup. No exclusions or prerequisites 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile. The description adds value by disclosing the return fields and clarifying that avatars made in the Vids web app are included, plus the cross-reference for resolving previewMediaId.

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?

Effectively one dense sentence that front-loads what gets listed, then the fields, then the resolution path. No filler, though the nested parentheticals make it slightly packed.

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

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

With no output schema, the description carries the return burden and mostly does so by enumerating the fields. It stops short of noting pagination or limits, but for a simple one-param list tool it is close to sufficient.

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

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

Schema coverage is 100% and the single email param is documented there ('Only this account. Default: every account.'). The description says nothing about the param, so the baseline 3 for high-coverage schemas 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+resource (list avatars) and enumerates the returned fields (avatarId, name, voice, previewMediaId). It distinguishes itself from other list siblings like vids_list_voices/list_accounts by resource, though it doesn't explicitly name them.

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 explicit when/when-not guidance against alternatives. The only routing text is a follow-up hint ('see it with vids_get_media' for previewMediaId), which is implied usage rather than selection criteria.

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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are limited to currently running jobs (not a full job history) and include an aggregate per-account count versus maxJobs.

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 short, front-loaded sentences with no filler; the scope statement comes first. The trailing 'GET /jobs' is mildly redundant with the tool name but cheap and useful for endpoint mapping.

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 zero-parameter read tool whose annotations already carry the safety profile and with no output schema to explain, the description covers what is returned (running jobs plus per-account counts). Minor gaps remain around cross-account scope and whether any pagination applies.

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, so the baseline is 4; there is nothing for the description to disambiguate. The schema is an empty object with additionalProperties false, matching the description's implied no-filter behavior.

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 concrete verb+resource (list of jobs running now) and specifies the returned scope, including per-account running counts against maxJobs. It implicitly separates itself from vids_get_job (single job) and the sibling list tools, but never names an alternative explicitly.

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

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

There is no when-to-use guidance, no exclusion (e.g. queued/completed jobs, other accounts' jobs), and no mention of alternatives such as vids_get_job for a single job's detail. Usage is only inferable from the phrase 'running now'.

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, destructiveHint=false and openWorldHint=true. The description adds genuinely useful behavior beyond that: the catalog is a fixed set of 30 entries and each entry carries name, id, style and preview audio URLs. It does not discuss pagination or caching, but for a static zero-param list this is reasonable coverage.

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 with the payload contents front-loaded and the endpoint appended as a trailing anchor. Nothing is padded, though the bare 'GET /voices' adds little for an agent that already has the tool name and schema.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers what the agent needs: what the collection is, how big it is, and what fields come back. No prerequisites or follow-up routing are described, which keeps it just short of fully complete.

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

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

The tool takes no parameters at all (schema is an empty object), so there is nothing for the description to disambiguate. Baseline 4 applies; the field list it gives is about the response, not inputs, and output schema is absent so that detail is a net gain.

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?

Identifies the resource precisely (the fixed catalog of Gemini voices) and enumerates the returned fields, so an agent can distinguish it from vids_list_avatars or vids_list_accounts without opening the schema. It is a noun-phrase description rather than an explicit verb, but the naming and content leave no ambiguity about what the call 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?

The phrase 'an avatar can speak with' implies this is the lookup step before creating or configuring an avatar, which is meaningful context. However, it never states when to call this versus other listing tools or as a prerequisite to vids_create_avatar, so usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the update is scoped to a single field and cites the underlying endpoint (POST /accounts), which is mildly useful context but does not explain error behavior or what happens to other account settings.

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 short sentences, front-loaded with the mutation and its field, no filler. The trailing endpoint notation is slightly redundant with the tool abstraction but costs little.

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

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

For a two-parameter, single-field mutation with no output schema, the description covers what changes and the value range, and annotations cover idempotency/safety. It omits any statement about return value or failure modes (invalid email, nonexistent account), leaving an agent to guess at error handling.

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 both parameters are already documented, including the 1-10 bound. The description adds only the clarification that maxJobs governs video and image jobs run concurrently — a marginal semantic gain over the schema's 'Jobs at once, 1-10.' Baseline 3 is correct.

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 ('Change'), resource ('an account'), and the exact field affected ('maxJobs'), so an agent can tell it apart from vids_get_account and vids_list_accounts. It stops short of naming those siblings explicitly, which is what would push it to a 5.

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 this is the tool for adjusting concurrency limits, but gives no when-to-use framing, no prerequisites (does the account need to exist?), and no pointer to the read/list siblings for inspection. Usage must be inferred entirely from the verb.

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 flag readOnlyHint=false and openWorldHint=true, but the description adds genuinely non-obvious traits: the asset is bound to the uploading account ('usable on that account only'), the source url must be public https, and there is a 50 MB ceiling. The one gap is that it never states re-uploading the same file yields a new assetId (consistent with idempotentHint=false), which matters for callers trying to avoid duplicates.

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 with nested parentheses, but every clause carries real information and the core action plus formats are front-loaded. The nested parenthetical lists are slightly harder to scan than a short bulleted structure would be, though nothing is 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 four-parameter creation tool with no output schema, the description covers the essentials: accepted formats, two input transports, size bound, account binding, and the returned assetId. It leaves open whether assets expire and how to enumerate existing assets, but those are secondary for a 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 coverage is 100%, so the baseline is 3; the description still earns above baseline by adding constraints absent from the schema, notably the 50 MB url limit and the guidance that contentBase64 is for 'small files' only. It also reinforces the account-scoping semantics of email, which is the parameter most likely to be set wrong.

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 ('Upload your own JPEG, PNG or WebP image') and immediately names the concrete downstream roles the resulting asset fills (startImage / referenceImage_N for vids_create_video, person photo or logo for vids_create_avatar). That makes it clearly distinct from siblings like vids_get_media or vids_list_avatars, which read rather than create assets.

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

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

Usage context is clear: this is the prerequisite step that feeds vids_create_video and vids_create_avatar, and the description tells the caller which transport to pick (public https url vs contentBase64 for small files). It stops short of explicit exclusions — e.g., it never says to use vids_get_media when the asset already exists in the account — so an agent must infer the boundary.

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 write (readOnlyHint=false), non-idempotent, non-destructive, open-world behavior. The description adds genuinely new context — this returns an async job rather than a finished video, and consumes 'seconds' of quota — but the 'seconds' phrasing is cryptic and it never says whether re-invoking spawns a duplicate job or that vids_get_job is needed to retrieve the result.

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

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

Three short sentences with the core action front-loaded and no filler. The middle sentence ('Uses the clip's seconds again') is too terse to parse confidently, and the trailing 'POST /videos/upscale' is endpoint trivia an agent cannot act on.

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 one-parameter, no-output-schema tool this is close to adequate: the async job nature is stated and the input constraint is implied. It falls short by not naming the polling tool or clarifying the quota language, which an agent needs to actually complete the workflow.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents mediaId fully, including that it must come from a finished video job's result. The description's '720p clip' adds no meaning beyond the schema. Baseline 3 applies when the schema does the work.

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 with concrete constraints: 'Turn a 720p clip of up to 20 s into 1080p.' An agent immediately knows the operation and its input bounds. It does not explicitly differentiate itself from siblings like vids_edit_video or vids_extend_video, which are the nearest alternatives.

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: 'A job, like vids_create_video' signals the async-job pattern and 'Uses the clip's seconds again' hints that quota/credits are consumed, but there is no explicit statement of when to choose upscale over edit or extend, nor any stated prerequisite beyond the schema's 720p requirement.

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