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

Annotations only declare readOnlyHint=true; the description adds valuable behavioral context by noting that qa_only or full pipeline is requird and that the tool works best on focused time ranges. There is no contradiction with the read-only annotation, and the additional constraints are not visible from structured fields 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 front-loaded with the main purpose, then organizes guidance into scannable bullets for workflows, single-video/cross-video usage, and follow-ups. Every section earns its place given the tool has 7 parameters and requires routing decisions.

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 format need not be explained, and the description covers the main invocation modes, pipeline requirement, and relationship to sibling tools. It is nearly complete, but the unmendtioned rationale parameter and lack of timestamp units are minor completeness gaps for a tool this complex.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the key parameters video_id, start, end, videos, and conversation_id with concrete usage scenarios, which is substantial added meaning beyond the bare schema. However, the optional rationale parameter is never mentioned, and exact timestamp units are unspecified, leaving small gaps.

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 a question-answering action over one or more videos using visual analysis, which separates it from siblings like get_transcript, summarize_video, and search_videos. It also explains single-video vs cross-video scope, so an agent understands what resource this tool operates on and how it differs.

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

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

Gives explicit workflow guidance: first use search_videos, segment_video, or get_transcript to gather context, then call ask_video. It also specifies parameter patterns for single-video, cross-video, and follow-up scenarios, clearly telling an agent when and how to invoke this tool versus alternatives.

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 empty annotations, the description carries the full behavioral burden. It discloses the core side effect (creating a new group) and the return values, but it does not address potential issues like duplicate names, permissions, persistence, or effects on existing videos. This is adequate for a simple create operation but not deeply transparent.

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 short sentences with no filler. The action is front-loaded, the context sentence earns its place, and the return-value sentence is concise. It is appropriately sized for a simple create tool.

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

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

For a low-complexity create tool with an output schema, the description covers the primary action and return value. However, it leaves the optional 'rationale' parameter unexplained and omits behavioral constraints like name uniqueness or permissions. It is usable 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 description coverage is 0%, so the description must explain the parameters. It does not mention 'name' or 'rationale' at all; 'name' is inferable from the schema title, but 'rationale' remains unclear. The description fails to compensate for the lack of schema-level 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 states a clear action ('Create'), a specific resource ('video group'), and the return value (ID and name). This differentiates it from sibling tools like list_groups, delete_group, and video-level 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 gives context ('Groups organize videos into collections') that implies when creating a group is useful, but it does not explicitly state when to use this tool versus alternatives or any exclusions. Usage guidance is largely implied 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?

The annotations already signal destructive and idempotent behavior, and the description adds valuable nuance: the operation does not delete videos, only their membership. This clarifies the practical impact of the delete beyond what the annotation flags 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?

The description is a single sentence that front-loads the core action and follows with the key exception. Every word contributes to understanding the operation.

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 destructive tool with an output schema and two parameters, the description covers the critical behavioral nuance and leaves the required identifier self-evident from the schema. It is slightly incomplete around the optional rationale semantics, but not enough to hinder correct invocation.

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

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

Schema description coverage is 0%, and the description provides no details about group_id or rationale. The required group_id is inferable from its name, but the optional rationale parameter is left completely unexplained, so the description does not compensate for the missing 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 opens with the specific action and object, 'Delete a video group,' which clearly differentiates this from sibling video operations like delete_video. The follow-up clarification that videos in the group are not deleted removes ambiguity about what the tool targets.

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 explanation that videos are simply removed from the group gives an agent clear context to choose this tool when the intent is to delete the group but preserve its videos. It does not explicitly name an alternative such as delete_video, so it stops short of full 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 mark the tool as destructive and idempotent. The description adds useful behavioral context by emphasizing permanence, irreversibility, and cascading removal of indexed data. This exceeds what the annotations alone reveal without contradicting 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?

Two focused, front-loaded sentences: the first states the operation and its full impact, the second warns about irreversibility. No extraneous content.

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 covers the destructive nature and the data affected, and output schema plus annotations carry some burden. However, with zero schema coverage, the description should have at least pointed to the required video_id parameter and explained the optional rationale, which it does not.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining the video_id or rationale parameters. No additional meaning is provided beyond the bare parameter names in 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 action ('Permanently delete a video') and resource scope ('all its indexed data'), listing concrete data types (transcript, captions, embeddings). This clearly distinguishes it from related siblings like update_video or delete_group.

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 effect of the tool is clear, but the description only implies when to use it by saying 'delete a video.' It does not explicitly mention alternatives or scenarios where this tool should not be used, such as when only removing a video from a group.

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 cover readOnly and idempotent behavior, so the description adds value by disclosing the segment-and-timestamp output model and the prerequisite captions feature. It does not contradict annotations and provides behavior beyond the structured fields.

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 paragraphs each carry distinct information: what the tool returns, how to scope it, and what feature it requires. There is 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 read-only tool with an output schema and annotations, the description covers the core selection and invocation context: purpose, scoping parameters, and feature prerequisite. It omits explanation of rationale and max_results, but those gaps are minor given the schema defaults and 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?

With 0% schema description coverage, the description should compensate for undocumented parameters. It adds meaning for start/end ('narrow results'), but it does not explain video_id, rationale, or max_results, leaving several parameters dependent on schema names/defaults.

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 ('Get AI-generated visual descriptions of what happens on screen') and clarifies the use case ('understand the visual content without watching'), which distinguishes it from transcript-based or scene-based siblings. Even without naming a sibling, the visual-caption framing removes 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?

It says to use this tool when you need to understand visual content without watching, and it notes that start/end narrow results and that captions require the qa_only or full pipeline feature. It does not explicitly name alternatives or exclusions, so it stops 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.

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

Annotations already mark the tool read-only and idempotent, and the description's 'List' wording is consistent with that. The description adds useful context beyond the annotations by promising that catalog entries include dependencies and descriptions and by positioning the call as a step before using index_video. No operational hazards exist to disclose for this safe catalog endpoint.

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 no filler or tautology. The first sentence states what the tool does; the second states why and how to use it. Every sentence earns its place.

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

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

For a simple, safe, read-only catalog endpoint with an output schema, the description covers the goal, the content of the catalog, and the connection to index_video. The only weakness is the unexplained rationale parameter, but it is optional and likely nonbehavioral, so the overall context is nearly 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 description coverage is 0%, and the only parameter, rationale, is not explained anywhere in the description. Since the description must compensate when parameter coverage is low, and it does not address the parameter at all, the description adds no semantic value for calling it correctly. The rationale parameter's role in the request remains unclear.

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

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

The description uses a specific verb ('List') and resource ('available video analysis features'), and further specifies that output includes dependencies and descriptions. It clearly distinguishes this catalog tool from sibling list operations like list_videos and list_groups. The tie to index_video makes the purpose concrete.

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 says to use this tool to understand what features exist and which pipelines to use with index_video, providing clear context. It does not mention when not to use it or name alternative discovery tools, so it stops short of full exclusionary 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 mark the tool read-only and idempotent, and the description adds the important prerequiste that transcript scene detection must be enabled and is disabled only when index_video was called with scene_detection=False. It also hints at typical scene lengths relative to segment_video's limit. This provides useful behavioral context beyond the structured annotations.

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

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

The description is compact and front-loaded: the core action appears in the first sentence, followed by a clear bulleted list of downstream uses and a one-line prerequiste. Every sentence contributes.

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

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

For a simple read-only retrieval tool with an output schema, the description covers purpose, downstream integration, and the indexing requirement. It is missing only brief parameter semantics for max_results and rationale, which prevents a 5.

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

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

Schema description coverage is 0%, so the description must compensate, but it only implicitly covers video_id. Neither max_results nor rationale is explained, and the default of 200 or its effect on returned scenes is left to inference.

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: 'Get detected scene boundaries with start/end timestamps.' This clearly distinguishes the tool from siblings like get_transcript or segment_video, and it is not a restatement of the tool name.

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

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

It explicitly says to use this first to understand video structure, then pass scene timestamps to ask_video and segment_video, including a note about segment_video's 15s max range. It also states the indexing prerequiste and the only case where scene detection is skipped. It stops short of naming alternative scene sources or explicit when-not conditions, so a 4 rather than 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?

Given readOnlyHint and idempotentHint annotations already cover safety, the description adds useful behavioral context: it returns verbatim text, supports range narrowing via start/end, and requires transcript indexing. It does not discuss failure behavior if the transcript is unavailable, but it exceeds the minimum bar.

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 short sentences with no filler. The core purpose is front-loaded, followed by usage guidance and a prerequisite, making it easy to scan and 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 read-only tool with an output schema and strong annotations, the main purpose and key prerequisite are covered. However, with 7 parameters and zero schema descriptions, the missing semantics for format, max_chars, max_results, and rationale leave noticeable gaps that an agent would need to resolve elsewhere.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only explains start/end as narrowing options. format, max_chars, max_results, rationale, and video_id receive no semantic explanation, leaving the agent to guess at their meaning and interaction.

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: 'Get the spoken words in a video.' It further disambiguates from ask_video by explicitly stating that it returns actual text rather than a summary, which makes the tool's purpose unmistakable.

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

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

The description gives explicit usage direction: use this instead of ask_video when you need to read what was said, use start/end to narrow results for long videos, and only use it when the transcript feature has been indexed. These are clear when-to-use and prerequisite signals.

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 signal readOnly and idempotent, but the description adds critical behavioral detail beyond them: the 'url' field is 'a short-lived HTTPS presigned URL (expires within hours)' and should not be stored. This materially changes how an agent should handle the response and is exactly the kind of non-obvious behavior the description should disclose.

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 sentences with no filler. The first sentence states scope and content, the second gives the intended use case, and the third provides the presigned URL caveat. Every sentence earns its place and the most important operational warning is front-loaded at the end of the paragraph.

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

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

The tool has an output schema, so return-value details do not need to be in the description. The description supplies the critical operational context: when to call it, what it returns conceptually, and how to handle the expiring URL. Nothing needed for correct invocation 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 description coverage is 0% and the description does not explain either parameter. 'video_id' is inferrable from the tool's purpose, but 'rationale' is opaque: it has no description and appears to be optional, yet the tool description never mentions it. With no schema descriptions, the description should carry meaning for parameters, but it does not.

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

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

The description begins with 'Get detailed information about a video', which is a specific verb and resource, and then enumerates the exact content: upload status, metadata (duration, resolution, fps), and per-feature indexing status. This clearly distinguishes it from sibling tools like list_videos or get_transcript, even without naming 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?

It explicitly states 'Use this to check if upload or indexing is complete', giving a concrete when-to-use scenario. It also warns to fetch the URL immediately and call again for a fresh one, which is operational guidance. It does not name alternatives or explicitly state when not to use it, so it stops short of the strongest possible 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 only provide idempotentHint, but the description discloses latency (3-7 minutes, longer for long/full), a 10-minute timeout, default scene detection behavior, pipeline side effects, and prerequisite status. None of this contradicts the idempotentHint annotation, and it gives the agent crucial expectations for a long-running 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?

The description is information-dense but well-organized: purpose, expected duration, pipeline modes, detection behavior, preconditions, and input modes. Each sentence contributes operational value, and the most decision-relevant details (timeout, status prerequisite, exactly-one parameter) are placed prominently.

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

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

For a tool with 5 parameters, no required fields, no schema-level descriptions, and meaningful sibling interdependencies, this description covers purpose, timing, timeout, prerequisites, pipeline options, defaults, and downstream tool enablement. Output behavior is covered by the output schema, and the only minor gap is the rationale parameter, which is optional and non-essential for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does for pipeline, video_id vs file_path, and scene_detection, including the 'exactly one' rule and defaults. The only paramter left unexplained is rationale, which is optional but still undocumented in both schema and description.

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

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

The description states a specific verb and resource ('Index a video') and goes further by enumerating the three pipeline modes and the downstream tools they enable (search_videos, ask_video, all tools). This clearly distinguishes index_video from the sibling tools while making its role in the workflow obvious.

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 explicit operational guidance: check the video is in 'uploaded' status and use get_video, provide exactly one of video_id or file_path, pick a pipeline, and optionally disable scene_detection. The description also implies sequencing by noting which downstream tools each pipeline enables. This is far beyond minimal viable usage 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 readOnlyHint and idempotentHint, so the safe, repeatable read profile is fully covered. The description adds the 'all groups' scoping detail, useful for setting expectations about filtering. It does not mention pagination or ordering, but the output schema covers the return shape; there is no contradiction with annotations.

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

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

Two sentences accomplish both core purpose and alternative routing with zero filler. Information is front-loaded: the primary function comes first and the alternative second. Every sentence earns its place.

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

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

Given the output schema and the readOnly/idempotent annotations, the description covers what the agent needs for selection and safe invocation of a simple listing tool. Its one gap is recommending list_videos, which is not in the provided sibling set, and it omits pagination/filtering caveats. On balance it is nearly complete for the tool's complexity.

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

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

Schema description coverage is 0 percent, and the sole 'rationale' parameter has no schema description; the tool description says nothing about it either. Because the description must compensate for low coverage but does not, it adds no information about how to fill the one argument. The parameter is optional and reasonably self-evident by name, which prevents a score of 1.

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 opening sentence 'List all video groups' names a specific verb and resource with an explicit 'all' scope, making the tool's function unambiguous. It also points to list_videos as the narrower per-group alternative, which reinforces what this tool is not. Clear enough to select correctly even before reading 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?

The description explicitly says to use list_videos with a group_id when the goal is videos in a specific group, which is actionable routing guidance. It does not cover other grouping alternatives (e.g., create_group/delete_group), and the referenced list_videos is absent from the provided sibling list, so it cannot be a 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 mark readOnlyHint and idempotentHint, so the safety profile is covered. The description adds high-value behavioral disclosure: URLs are short-lived presigned HTTPS links that expire in hours, must be fetched immediately, should not be stored, and can be refreshed by calling list_videos or get_video. This goes well beyond the annotations.

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

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

Three sentences, all informative: purpose+filter, output hints, and URL lifetime warning. The most critical scoping fact is front-loaded, and no sentence 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 read-only list operation, the description covers the core behavior, the optional filter, output contents, and the ephemeral URL caveat. The output schema fills in return details. The only meaningful gap is the undocumented rationale parameter, which keeps this from being 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?

group_id is well explained as an optional filter to a specific group. However, the second parameter, rationale, is completely unexplained in both the schema (0% coverage) and the description, so an agent cannot know what value to provide or why it exists. With such low schema coverage, the description needed to compensate for both parameters but covers only one.

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 clear verb and resource: 'List all videos in your account' and immediately defines the optional group_id filter. It also previews output fields (upload status, indexed features), making the tool's scope unambiguous. The 'all videos' framing distinguishes it from singular or search-oriented siblings, even without naming them 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?

It tells the agent exactly when to call this tool: for the full account inventory or a group-scoped list via group_id. It doesn't name alternatives or state when not to use it, and the only sibling referenced indirectly is get_video for refreshing URLs. This is clear context, but not full when/when-not coverage.

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 readOnlyHint/idempotentHint annotations, the description discloses that returned video_urls are short-lived presigned URLs that expire within hours, advises to fetch immediately and not store, and explains how to get a fresh URL. It also states that results are ranked by relevance and mentions auth requirements. No contradiction with annotations.

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

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

The description is front-loaded with purpose and usage guidance, and each paragraph adds behavioral or auth context. There is a slight redundancy between 'recommended first step' and 'instead of asking ask_video...' but overall it is tight and well-structured.

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

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

The output schema covers return values, and the description covers URL expiration, auth, and when to use it. However, with 5 parameters and zero schema-level descriptions, the optional parameters—especially rationale—are not documented anywhere. The tool is usable for the main search path but not fully specified for a correct call using all filters.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter meanings, but it doesn't explain group_id, video_ids, rationale, or max_results semantics. The purpose makes 'query' obvious from context, and the schema provides defaults/types, but optional filtering parameters and 'rationale' remain unclear. This is a significant gap.

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

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

The description clearly states what the tool does: 'Find WHEN and WHERE something happens across your videos' and explains that it returns timestamped results ranked by relevance. It also distinguishes itself from ask_video by saying to use these timestamps as start/end in ask_video, so an agent can tell them apart.

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

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

It explicitly positions this tool as 'the recommended first step for most questions' and tells the agent to 'search first' instead of asking ask_video about the entire video. It also explains how to chain it with ask_video by using returned timestamps as start/end, and notes permission requirements ('Requires search_only or full pipeline').

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 mark readOnly and idempotent; description adds behavioral detail beyond that: per-frame outputs, prompt reliability caveats, 15-second maximum range, and no requirement for feature indexing. No contradiction with annotations.

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

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

Well-structured with clear sections for prompt tips and time-range selection; every sentence adds value. Front-loaded with the core purpose before implementation guidance.

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?

Covers the core usage workflow, constraints, and output nature, and an output schema exists to fill in return-value details. Missing semantics for the optional threshold and rationale params, but defaults and the rest of the description make the tool safely callable.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains prompts (broad categories vs specific labels) and time-range semantics (15-second windows, consecutive calls), but leaves threshold and rationale parameters undocumented. Partial compensation.

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 specific verb and resource: 'Detect objects in a video segment using text prompts' and clarifies output as per-frame detections with bounding boxes and confidence scores. This distinguishes it from sibling video tools like search_videos or get_scenes.

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

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

Provides explicit when-to-use guidance: best for confirming object category presence, not precise identification. Gives a clear workflow with search_videos and get_scenes, plus the 15-second call limit and multi-call strategy.

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 provide readOnlyHint and idempotentHint, so the safety profile is clear. The description adds behavioral context about what the overview contains (metadata, indexed features, transcript preview, scene count) and signals it is a low-risk, high-level inspection step. No contradiction with annotations.

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

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

Three sentences with no filler. The most actionable guidance ('Start here') is front-loaded, followed by a clear list of outputs and a pointer to the next tool. Every sentence earns its place.

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

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

With an output schema present, return values are already defined, so the description only needs to provide entry-point context, content summary, and routing—all of which are present. The tool's role within the larger workflow is fully specified.

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

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

Schema description coverage is 0%, and the description provides no parameter-level detail. It implies video_id refers to the video being summarized, but the optional rationale parameter is completely unexplained, leaving a gap for the agent. Some credit for resource context, but it does not compensate for the lack of schema coverage.

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

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

States a specific verb ('Get a compact overview') and enumerates the resource contents (metadata, indexed features, transcript preview, scene count), clearly distinguishing it from siblings like get_video or get_transcript. The phrase 'Start here' also establishes its unique entry-point role.

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 positions the tool as the first step ('Start here') and tells the agent to use it to decide which tools to call next. It also names the next appropriate sibling, segment_video, for detecting specific objects, leaving no doubt about when to use this tool versus alternatives.

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 idempotentHint annotation, the description discloses that updates are partial (at least one field required) and that a null group_id has removal semantics. This goes beyond the structured metadata, though it doesn't address auth, side effects, or what happens to unspecified fields.

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 concise sentences: the first states the operation and target fields, the second states the required condition and a special null case. Every sentence adds useful 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?

For a 7-parameter mutation with no property descriptions and minimal annotations, the description covers the main update paths but omits the rationale and move_group semantics, and it doesn't clarify the group-move mechanics beyond null removal. The output schema covers return shape, so that gap is acceceptable.

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

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

With 0% schema description coverage, the description must compensate. It clarifies name, title, description, and group_id behavior, but leaves rationale and move_group unexplained, including how move_group interacts with group_id. So compensation is only partial.

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 ('video') and the action ('update') and then enumerates the mutable aspects: display name, title, description, or group membership. This is specific enough to distinguish it from sibling tools like delete_video, upload_video, or get_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 gives concrete call conditions: at least one field must be provided, and group removal requires group_id to be null. It does not explicitly contrast the tool with alternatives, but the update context is clear.

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 empty annotations, the description carries the full burden and delivers well: it discloses the asynchronous upload, the returned video_id, rejection of local file paths, and the required polling handshake before the video is usable. It stops short of describing failure behavior for unreachable URLs or auth/permission requirements, which are material gaps for a write operation with zero annotation 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?

Three sentences, front-loaded with purpose and return value before the constraints and workflow. Every sentence carries operational information — no filler, no tautology, and the critical async caveat appears early.

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 5-parameter async ingest tool with an output schema present, the description covers the essential operating loop (upload → poll → index) and the key input constraint. It omits failure handling and the intended purpose of the optional parameters, but the workflow guidance is sufficient for an agent to invoke it correctly in the common case.

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

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

Schema description coverage is 0%, and the description compensates for the one required parameter (video_url) with explicit semantics: a reachable URL is mandatory and local paths are rejected. The four optional parameters (name, group_id, rationale, description) receive no additional meaning beyond their property names, so compensation is only partial.

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 ('Upload a video from a URL. Returns a video_id.') and clarifies what upload means relative to the sibling index_video, which is explicitly positioned as the follow-up step that enables search and analysis. An agent can distinguish it from get_video, list_videos, and index_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 an explicit operational workflow: upload → poll get_video until status is 'uploaded' → call index_video, plus a hard prerequisite that video_url must be reachable and not a local file path. However, it never states when not to use this tool or how to choose among alternatives, so the guidance is contextual rather than exclusionary.

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