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

With no annotations, the description carries the transparency burden and discloses key behaviors: it downloads the video, sends it to Gemini, returns a video_id, and instructs the agent to reuse that ID instead of re-downloading. It also clarifies that a user-provided public URL is treated as authorized. However, it does not mention retention duration, deletion, or local-file handling, leaving some behavioral gaps.

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

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

The description is three concise sentences that front-load the trigger conditions, then give the workflow and follow-up instruction. Every sentence earns its place, with no filler or repetition.

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

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

The description gives a complete workflow for public URLs, including authorization, download, analysis, video_id return, and follow-up via ask_video. It is slightly incomplete because it never mentions the file_path local-video path from the schema, nor does it explain retention or deletion semantics beyond 'do not re-download.'

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 parameter descriptions already explain url, mode, question, and file_path. The tool description adds little beyond the schema, mostly repeating the URL authorization note already present in the schema. Baseline of 3 is appropriate because the schema does the heavy lifting.

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 exactly what the tool does: analyze a public video URL and retain it for follow-up, with a specific verb and resource. It also distinguishes the tool from siblings like ask_video by explicitly reserving follow-up questions for ask_video, and from download_video by noting the download is a means to analysis.

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 says 'Use whenever the user pastes a public video URL or asks for a visual, animation, movement, music, transcript, or shot-by-shot breakdown,' giving clear trigger conditions. It also explicitly instructs to use ask_video for every follow-up and not to re-download, thereby naming the alternative and exclusion.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions the ability to ask questions and inspect timestamps, but does not disclose any side effects, conversation state, rate limits, or whether this is purely a read operation. This is a significant gap for a tool that may rely on prior analysis context.

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

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

The description is two sentences, front-loaded with the action and resource, and every phrase adds value. It avoids redundant wording and is highly scannable.

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

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

Given the simple tool (2 params, no output schema), the description covers the core purpose and usage context. However, it does not explain the response format, potential errors, or whether the conversation context persists, which would be useful for an AI agent deciding whether to use it. It is adequate but not 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?

Schema coverage is 100%, with each parameter having a meaningful description. The tool description adds context about the purpose (follow-up questions) but does not significantly enhance the parameter semantics beyond what the schema already provides, so the 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 uses specific verbs ('ask', 'inspect') with a clear resource ('previously analyzed video') and lists concrete use cases (new questions, different detail, specific timestamp). It also distinguishes itself from siblings by explicitly saying to use this instead of re-downloading or uploading the 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 description clearly states when to use this tool: for follow-up questions on an already analyzed video, and explicitly advises against downloading/uploading again. However, it does not explicitly name alternative tools or state when not to use it (e.g., for new videos), so it falls just short of full guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the video is saved to a private local folder, that the URL is treated as authorized, and that the tool will not circumvent protections. This gives the agent a clear model of the tool's safety boundaries, which is valuable beyond the input schema alone.

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

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

The description is two sentences, with the primary action front-loaded and the constraint sentence adding necessary guidance. Every word earns its place; no filler or repetition.

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

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

For a simple one-parameter tool, the description covers purpose and constraints, but it omits any information about the return value or outcome (e.g., whether it returns a file path, success message, or error). Since there is no output schema, this gap makes the description only minimally complete for an agent that needs to know what to expect after invocation.

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

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

The schema already fully describes the 'url' parameter with 100% coverage (format, type, description). The tool description adds that the URL is 'user-provided' and 'authorized', which is mild extra context but not essential. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the action ('Download a user-provided public video') and the destination ('Video Intelligence's private local downloads folder'). This distinguishes it from sibling tools like analyze_video and ask_video, which operate on videos already available.

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

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

The description provides clear context for when to use the tool (downloading public videos) and includes an explicit exclusion: 'do not bypass DRM, paywalls, logins, private links, or platform protections.' It does not name alternative tools, but the sibling list makes it obvious that this is the download step before other operations.

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

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

With no annotations, the description carries the full burden. It discloses the immediate destructive action ('Immediately delete') and the additional side effect of removing the local session record. This goes beyond the name and title, though it does not specify irreversibility or idempotency.

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

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

The description is a single, front-loaded sentence that states the action and purpose without wasted words. It earns its place by adding context about timing and the local record.

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

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

For a simple deletion tool with one parameter and no output schema, the description adequately covers what is deleted, when to use it, and the side effect. It does not mention error handling, but that is not essential for basic usage.

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 parameter 'video_id' already describes its source from analyze_video. The tool description adds no extra parameter semantics, so the baseline 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?

The description clearly states the verb 'delete' and the target resources: 'uploaded Gemini file' and 'local session record'. It distinguishes from sibling tools which analyze, ask, download, or check status, so the delete purpose is unambiguous.

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

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

The description provides a clear context for use: 'when the user is finished asking follow-up questions'. It does not explicitly mention when not to use or name alternatives, but the context is sufficient to guide the agent on timing.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is a configuration check, but it doesn't state whether it's read-only, what the output looks like, or how to interpret the result. It adds little beyond the title and could be more transparent about the check's behavior.

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

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

The description is a single, front-loaded sentence that efficiently conveys purpose and context without 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?

Given the tool's simplicity, the description covers its main purpose and usage. However, with no output schema and no annotations, it omits details about the returned status or behavior when the server is unconfigured. This leaves a gap for a tool that primarily returns a status.

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

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

The input schema has zero parameters, so there is nothing to document. The baseline for zero-parameter tools is 4, and the description correctly makes no claims about parameters.

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

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

The description clearly states the tool's function: checking whether the local video-analysis server is configured. It uses a specific verb ('check') and resource ('server configured'), and it distinguishes from sibling tools by framing it as a prerequisite check for download and analysis operations.

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 explicitly states when to use this tool: 'before attempting a download or Gemini analysis.' This references the sibling tools (download and Gemini analysis) and gives a clear temporal context. It doesn't explicitly list alternatives or exclusions, but the usage context is well-defined.

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