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

The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context that partial files are discarded and finished downloads are unaffected, which goes beyond what the annotations state.

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

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

Two sentences with no wasted words; the core action and scope are front-loaded, and the secondary clarification about finished downloads follows naturally.

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 one required parameter, full schema coverage, and explicit annotations, the description covers the necessary behavior. It does not explain the return value, but no output schema exists and the operation is simple enough that this is a minor gap.

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

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

Schema coverage is 100%, and the single parameter is fully described in the schema as the id returned by download_video. The description adds no further parameter meaning, so the baseline score of 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+resource ('Stop a queued or running download') and explicitly scopes the operation ('discard its partial file'), making clear it is not a status check or a new download. The distinction from siblings like get_download_status and download_video is implicit but readily apparent.

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

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

The description implies when to use it by specifying 'queued or running' downloads, but it does not explicitly say when not to use it or name alternatives such as get_download_status for monitoring. No explicit alternative or exclusion guidance is provided.

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

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

Annotations already declare not-readOnly, openWorld, non-idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result is a temporary (expiring) link and there is an async job fallback governed by wait_seconds. It stops short of stating link TTL, size limits, or whether repeated calls re-download.

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 the primary outcome front-loaded and the async escape hatch second. 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 must describe returns, which it does: a temporary link or a job id. For a 4-parameter, single-required-URL tool that is close to complete; only link lifetime and storage/expiry details are 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 description coverage is 100%, so all four parameters, including quality format strings and the audio_only default, are already documented. The description's mention of wait_seconds largely restates the schema's own wording, adding little new 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 (download), resource (video or audio track), and the return value (a temporary download link). The follow-up sentence covers the async fallback path, so an agent knows exactly what this produces without opening the 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?

Explains the wait/failover branch clearly: it completes within wait_seconds for most videos, otherwise hand the job id to get_download_status. It does not explicitly direct the agent to get_video_info before choosing a quality, but the schema's quality description does.

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 closed-world, so the safety profile is fully covered. The description adds context beyond that: the useful disclosure that the returned download_url is temporary and only present when status is "done", which tells the agent to consume it promptly.

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 with zero waste; the core check action is front-loaded and the important result caveat follows immediately. Nothing could be removed without losing 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 no output schema, the description carries the burden of explaining return values, yet it only documents the "done" case. It says nothing about other possible status values, what the result looks like while still running, or what happens if wait_seconds elapses before completion – all material for a polling 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% and both parameters (job_id sourced from download_video, wait_seconds with default 20 and 0-120 bounds) are documented in the schema itself. The description adds no parameter-level detail 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?

"Check a download" gives a specific verb and resource, and the mention of a terminal "done" status plus download_url makes the polling purpose unambiguous. Sibling differentiation is only implicit (job_id ties it to download_video), but the name and description together leave no doubt about which tool handles status vs. cancel or fetch.

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 a poll-after-download workflow but never states when to call it or how it relates to download_video and cancel_download. There is no explicit guidance on when not to use it or how to sequence it against the siblings, leaving the agent to infer the usage pattern.

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, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds genuine value by enumerating what the response contains and confirming no download side effect occurs. It omits failure behavior for unsupported links or rate limits, keeping it at a 4.

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 sentence that front-loads the resource and the returned fields, with the most important disambiguation ('without downloading it') placed at the end where it lands cleanly. 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 one-parameter, read-only, idempotent lookup with rich annotations and no output schema, the description is essentially sufficient and even previews the return fields. It leaves unstated what happens on an invalid or unsupported link, 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 coverage is 100%, and the schema itself already says 'Link to ONE video, reel, short or post (not a playlist or channel)'. The description adds nothing about the url parameter, so the baseline 3 applies — the schema does all the parameter 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?

Specific verb (look up) plus the exact fields returned (title, duration, uploader, available qualities), and it explicitly separates itself from download_video by stating 'without downloading it'. An agent can distinguish this from its three siblings 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?

The clause 'without downloading it' implicitly defines the use case as inspection-before-download and rules out the download path, effectively routing toward download_video for the other case. No explicit 'use X instead' sentence or prerequisite mention, so it falls short of a 5.

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