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

Beyond the annotations (destructiveHint=true), the description discloses concrete behavioral details: 'skips an already-indexed video by default', 'force_reembed=true deletes and replaces that video's existing local chunks and vectors', and 'may contact YouTube'. It also states the return value ('indexing status and chunk count'), which is useful since no output schema is provided. 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 three sentences, each serving a purpose: first states what it does, second gives usage context (sequence and default behavior), third discloses side effects and return info. No redundant or vague language.

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 moderate complexity (3 params, 2 required, no output schema), the description covers the essential aspects: purpose, prerequisite (corpus_create), default behavior, side effects, external interaction, and return value. It is complete enough for an agent to select and invoke the tool correctly without ambiguity.

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 baseline is 3. The description adds extra meaning for 'force_reembed' by explicitly explaining that it 'deletes and replaces that video's existing local chunks and vectors', which is beyond the schema's 'Re-embed even if already indexed'. It also clarifies the default skip behavior, providing context not fully captured 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?

The description clearly states the tool's function: fetching a transcript, chunking it, and storing local embeddings in an existing corpus. It uses a specific verb 'add' (implied) and distinguishes itself from sibling tools like youtube_get_transcript and corpus_search by focusing on indexing into a corpus.

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 'Use this after corpus_create', giving a clear sequencing context. It also explains the default skip behavior and the force_reembed alternative. However, it doesn't explicitly name alternatives or exclusions (e.g., 'if you just need a transcript, use youtube_get_transcript'), so it falls short of the highest benchmark.

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 indicate mutation (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds the valuable note that 'Each corpus uses a fixed embedding model', but doesn't disclose other behavioral traits like side effects or confirmation 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 with no redundant words. It efficiently communicates the tool's core purpose and one key constraint (fixed embedding model).

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 creation tool with two well-documented parameters and no output schema, the description is adequate. It conveys the essential context (creation, use case, embedding model constraint). It could mention what happens on duplicate corpus_id, but the idempotentHint partially covers that.

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 provides 100% coverage of parameters, including descriptions for corpus_id and label. The description's phrase 'named corpus' implicitly aligns with corpus_id, but adds no additional semantic detail beyond 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 uses the specific verb 'Create' with the resource 'corpus' and clearly states its purpose: 'for semantic search over transcripts'. This distinguishes it from sibling tools like corpus_add, corpus_search, corpus_list, and corpus_delete.

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: it's for creating a named corpus for semantic search over transcripts. While it doesn't explicitly mention alternatives or exclusions, the context makes it apparent when to use this tool versus corpus_add or corpus_search.

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 indicate destructiveHint=true and idempotentHint=true. The description adds the specific behavior that all chunks/vectors are deleted permanently, which goes beyond the annotations. No contradictions; the added details are useful for understanding the full impact.

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 conveys all necessary information without redundancy. It is front-loaded with the verb and object, making it immediately understandable.

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 delete operation with one parameter, the description fully covers the action and its consequences. The annotations and schema provide additional safety and parameter details, so no further context is needed.

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 100% description coverage for corpus_id with a clear description. The tool description does not add further semantics, but the baseline of 3 is appropriate because the schema handles parameter meaning adequately.

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 action ('Delete a corpus') and the scope ('all its chunks/vectors permanently'). This clearly differentiates from sibling tools like corpus_create, corpus_add, corpus_search, and corpus_list, which all have distinct purposes.

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 usage for permanent deletion but does not explicitly mention when to use it versus alternatives or any exclusions. There is no mention of prerequisites or cautions, but the destructive nature is clear. The tool is straightforward enough that the lack of explicit alternatives is acceptable.

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 indicate this is a read-only, idempotent, non-destructive operation. The description adds value beyond those by specifying the response includes chunk and video counts, which is not provided in any schema. This gives the agent a better idea of what to expect from the 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 a single, front-loaded sentence that states the verb, resource, and key output detail without any fluff or redundancy. Every word 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 parameterless list tool with strong annotations, the description is sufficiently complete. It tells the agent that the tool lists all corpora and includes chunk and video counts, which is enough to use it correctly. However, it could be slightly clearer about whether counts are per corpus or totals.

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?

There are no parameters, and the schema is empty, so the description does not need to add parameter-level detail. The baseline score of 4 applies because no parameters exist and the description provides sufficient context for the tool's 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 uses the specific verb 'List' with the resource 'all available corpora', and adds that it includes 'chunk and video counts', clearly distinguishing it from sibling tools like corpus_create, corpus_add, corpus_search, and corpus_delete. This makes the tool's purpose 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 implies usage when an agent needs to see all corpora and their counts, but it does not explicitly name alternatives or state when not to use it. Since the tool is a simple list-all operation, the context is clear, but there is no explicit guidance relative to sibling tools like corpus_search.

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, and non-destructive behavior. The description adds meaningful behavioral context: deduplication of overlapping windows, limiting source domination, and returning titles plus timestamp URLs. This goes beyond the annotations and helps the agent understand how results are processed and what to expect.

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, well-structured sentence that front-loads the core purpose ('Semantic search within a corpus') and then efficiently adds key behavioral details. There is no wasted wording, and every clause contributes meaningful 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?

Given the absence of an output schema, the description compensates by stating the return format (titles plus timestamp URLs). It also mentions deduplication and source domination limits, which gives a good sense of behavior. However, it does not elaborate on the meaning of 'source domination' or any edge cases, but this is acceptable for a straightforward search 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?

The input schema covers 100% of the parameters with clear descriptions (query, top_k, corpus_id), so the baseline is 3. The tool description does not add any additional parameter-specific semantics beyond what the schema already provides.

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 performs semantic search within a corpus, using 'search' as the verb and 'corpus' as the resource. It further distinguishes itself by noting deduplication, source domination limits, and the specific output format (titles plus timestamp URLs), which differentiates it from sibling YouTube search and corpus management tools.

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 'Semantic search within a corpus' implies the usage context, but there is no explicit guidance on when to prefer this tool over alternatives or when not to use it. The sibling tools have distinct names and purposes, but the description does not directly mention alternatives or exclusions.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by listing the documentation's scope (available tools, architecture, known limitations, API key setup), giving the agent insight into what information will be returned. No contradictions with annotations; the description complements them well.

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, well-structured sentence that starts with the action ('Get') and immediately specifies the resource and content. Every word is information-dense, with no redundancy or 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 zero-parameter, no-output-schema documentation tool, the description is fully complete. It explains what the tool does and what the documentation covers, which is all an agent needs to decide to invoke it. The lack of parameters and simple read-only nature mean no additional context is required.

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 the baseline is 4. The description does not need to explain parameter meanings, as there are none. It correctly focuses on the tool's purpose rather than inventing parameter details.

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 purpose: 'Get tube-bridge documentation' and enumerates the specific content covered (available tools, architecture, known limitations, API key setup). The verb 'Get' plus the resource 'documentation' unambiguously identifies this as an informational tool, distinguishing it from operational siblings like youtube_search_channels or corpus_create.

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 makes the usage context clear: this is the tool to retrieve documentation about the tube-bridge system. While it does not explicitly contrast with alternatives, the sibling tools are all operational (search, get info, create corpus), so the purpose inherently implies when to use this help tool. It lacks explicit 'use this when' or 'instead of' guidance, but the context is sufficiently 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful behavioral detail that the output distinguishes between manual and auto-generated subtitles, which is not captured by annotations. However, it does not disclose return format, pagination, or other potential behaviors, so the description adds only modest 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 short sentences: 'Available subtitle languages for a video. Shows manual vs auto-generated.' Both sentences carry meaningful information, and the key differentiator is front-loaded. No wasted words.

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 (single parameter), rich annotations, and no output schema, the description adequately conveys the core purpose and the manual/auto-generated distinction. However, it does not specify the exact return format (e.g., language codes, labels, structure), which would be helpful since no output schema exists. Still, for a simple read-only tool, it is largely 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 schema covers 100% of parameters with the description 'YouTube video URL or ID', so the baseline is 3. The tool description provides no additional meaning about the 'url' parameter beyond what the schema already states, so no extra credit is warranted.

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 identifies the resource ('available subtitle languages for a video') and adds a distinguishing feature ('Shows manual vs auto-generated'), differentiating it from siblings like youtube_get_transcript and youtube_get_video_info. Though it lacks an explicit verb, the tool name and context make the retrieval purpose clear.

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

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

The description implies the tool is for checking which subtitle languages are available, but it does not explicitly state when to use this tool vs alternatives like youtube_get_transcript or youtube_get_video_info. No exclusions or alternative guidance is provided, so the usage context is implied rather than explicit.

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, openWorld, idempotent, and non-destructive behavior. The description adds the auth requirement (YOUTUBE_API_KEY) but does not disclose rate limits, failure modes, or response structure, which would enhance transparency.

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 concise sentence that front-loads the key deliverable (channel metadata) and the auth requirement. Every word adds value, with no unnecessary fluff.

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 get-by-ID tool with comprehensive annotations and no output schema, the description adequately covers the metadata returned and the API key prerequisite. It omits potential error behavior but this is not critical for such a straightforward read operation.

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% for the single parameter channel_id, which includes a description of the expected format. The description adds no further parameter-level information, so a 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?

The description clearly states the tool retrieves detailed channel metadata, listing specific data types (subscribers, views, videos, country, keywords). This distinguishes it from siblings like youtube_get_video_info and youtube_get_channel_videos.

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 usage for obtaining detailed metadata for a known channel ID, but it does not explicitly state when to use this tool versus alternatives like youtube_search_channels. No exclusions or alternative tool mentions are 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?

Despite annotations already covering read-only, idempotent, and non-destructive, the description adds keyless access, normalized return structure, and empty-result warning behavior. This is meaningful 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?

Three concise sentences front-load the core action, then usage guidance, then behavioral details. No redundant words, every sentence adds value.

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 list tool with no output schema, the description covers purpose, usage boundaries, return composition, and edge-case behavior. This is complete enough for an agent to invoke confidently.

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 both parameters described. The description repeats channel_url (@handle) and limit (max count) without adding new semantic details 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?

Clearly states it lists recent uploads from a channel URL or @handle, with a specific verb and resource. Explicitly distinguishes from keyword search and channel metadata, aligning with sibling tools like youtube_search and youtube_get_channel_info.

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: 'Use this for channel browsing, not keyword search or channel metadata.' This tells the agent the intended context and excludes common alternatives, making selection straightforward.

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 destructiveHint, and the description adds meaningful context: requires YOUTUBE_API_KEY, returns structured comment records, and enumerates failure scenarios (comments disabled, video unavailable, quota exhausted). This goes well beyond annotations and helps the agent anticipate errors.

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, each earning its place: purpose, use case, and behavioral notes. Information is front-loaded and there is no redundancy or fluff.

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 (2 params, read-only, no output schema), the description covers purpose, usage boundaries, auth requirements, return type, and failure modes. It is fully sufficient for an agent to select and invoke the tool 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 description coverage is 100%, so both parameters are already documented. The description mentions max_results but adds no new semantics beyond what the schema states. Baseline 3 applies because structured data carries the burden.

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 retrieves top-level comments for a YouTube video, using the specific verb "Retrieve" and resource. It distinguishes from siblings by explicitly saying "not video metadata or transcripts," making it unique among the tool list.

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 clear context: "Use this for audience reactions," and excludes metadata/transcripts. It does not name alternative tools directly, but the sibling list and exclusions imply the boundaries. This is strong but lacks a named alternative, so not 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?

The description adds meaningful behavioral context beyond the annotations (readOnly, idempotent, destructive=false). It discloses that the returned JPEG is ephemeral, that extraction is best-effort, and that the timestamp is approximate ('near'), which is valuable for setting expectations. It also states the return format (metadata plus MCP ImageContent). 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 two sentences with no filler. The core function leads, and the second sentence efficiently covers return type and accuracy limitations. It is appropriately sized for the tool's complexity and well front-loaded.

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

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

For a relatively simple read-only extractor, the description covers the essential return value (metadata plus image), accuracy limits, and the schema covers all parameters. The annotations handle safety. It lacks some details like error cases or authentication, but these are not critical given the readOnly/idempotent hints and the tool's narrow scope.

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 covers all parameters (100% coverage), so the baseline is 3. However, the description's phrase 'near an integer-millisecond timestamp' adds precision semantics to timestamp_ms, clarifying that the given value is a target rather than an exact millisecond. This goes beyond the schema's simple 'Frame timestamp in integer milliseconds.'

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 specific action: 'Extract one ephemeral JPEG near an integer-millisecond timestamp.' This uses a strong verb ('extract') and a concrete resource (a JPEG frame), and it is distinct from sibling tools that search or retrieve metadata/transcripts. It immediately communicates the tool's purpose.

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 usage context (when a video frame is needed) but provides no explicit guidance on when to choose this tool over siblings or any exclusions. Unlike the calibration example, it does not name alternative tools or describe scenarios where this tool is not appropriate. The 'near a timestamp' phrasing does hint at precision trade-offs but not usage boundaries.

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, open-world, and non-destructive behavior. The description adds valuable context beyond annotations: it states the tool is keyless, returns playlist metadata plus ordered video records, results are bounded by limit, and failures occur for private/unavailable/blocked playlists. This fully complements the annotation set.

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 cover the core action, usage boundaries, and failure modes without any redundant phrasing. Every sentence contributes meaningful information, and the structure is front-loaded with the primary action.

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 small parameter count, rich annotations, and no output schema, the description covers all essential aspects: input requirement (known playlist URL), return content (playlist metadata + ordered videos), execution bound (limit), and likely failure conditions. It is complete for this simple 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% for both parameters, so the description is not required to add much. It reinforces the meaning of `limit` ('up to `limit` videos') but does not introduce new parameter-specific details beyond what the schema already says.

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 ('videos from a known YouTube playlist URL') and scopes the operation ('up to `limit` videos in upstream order'). It explicitly distinguishes from sibling alternatives by stating 'not channel uploads or keyword search', making the purpose 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?

It gives clear when-to-use guidance: 'Use this for playlist contents, not channel uploads or keyword search.' This identifies the appropriate context and excludes alternatives, though it does not name specific sibling tools as in the highest-caliber examples.

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 behavioral context beyond the read-only and idempotent annotations by explaining language selection behavior: it uses the original/default language and prefers manually created subtitles over ASR-generated ones. This helps the agent understand what transcript it will receive but does not cover potential edge cases like missing transcripts.

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 extremely concise—two short sentences—and front-loads the core purpose in the first sentence. The second sentence adds a key behavioral detail without unnecessary fluff.

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 tool with only three parameters and no output schema, the description adequately conveys purpose and key behavior. It does not mention failure cases or output format, but annotations and schema cover safety and parameter details, making it complete enough for this 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?

The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying that the lang parameter defaults to the video's original language and that manual subtitles are preferred over ASR, which supplements the parameter description and agent understanding.

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 returns the transcript/subtitles of a YouTube video, which distinguishes it from sibling tools like youtube_get_video_info or youtube_get_frame. However, it is phrased as a noun phrase rather than an explicit verb+resource action, so it is clear but not maximally explicit.

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 intended use case is implied by the description: retrieving transcript text for a YouTube video. There is no explicit mention of when to use this tool over alternatives, nor any exclusions. The note about original/default language and manual > ASR gives context but no direct alternatives are named, so usage guidance is implied rather than explicit.

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, it discloses auth needs (Data API v3 vs keyless yt-dlp fallback), return contents (source metadata and video records), and variability over time. This adds meaningful behavioral context without contradicting the read-only/idempotent hints.

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

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

The description is three sentences with no fluff. It opens with the main purpose, then usage guidance, then behavioral notes, making it well-structured and efficiently front-loaded.

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

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

For a single-parameter list tool with no output schema, it covers purpose, usage boundaries, data source behavior, and return contents. This is complete enough for an agent to select and invoke it appropriately.

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 documents 'limit' with 'Max results (default 10)' at 100% coverage. The description repeats the parameter name but doesn't add additional semantic meaning beyond 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 uses the specific verb 'List' with the resource 'currently trending YouTube videos' and scope 'up to limit'. It also explicitly distinguishes itself from keyword search, which differentiates it from the sibling youtube_search tool.

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 'Use this for broad discovery, not keyword search', providing clear when-to-use context and an exclusion. It also mentions the data source fallback and that results change over time, but it doesn't name the exact alternative tool (e.g., youtube_search).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the specific metadata fields returned, which is useful context beyond annotations. However, it does not disclose any limitations, error conditions, or response format, which is acceptable given annotation coverage but not exceptional.

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, well-structured sentence that lists the key metadata fields. It is front-loaded and every word adds value, with no redundancy or irrelevant information.

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

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

For a simple one-parameter read-only tool with no output schema, the description adequately conveys the purpose and return content by listing metadata fields. It does not mention caveats like video availability or authentication, but given the simplicity and annotations, it is sufficiently 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 schema fully describes the only parameter 'url' as 'YouTube video URL or ID' (100% coverage). The description adds no additional meaning about the parameter, so it relies entirely on the schema. 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 clearly states the tool provides detailed metadata for a YouTube video, listing specific fields (title, duration, views, channel, description, tags). This distinguishes it from sibling tools like channel info or search. However, it lacks an explicit verb like 'retrieves' or 'returns', so it's not a perfect 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 the tool is for fetching metadata of a specific video, but it does not explicitly state when to use it over alternatives like youtube_get_channel_info or youtube_search. No exclusions or comparison to siblings are provided, so only implied usage is present.

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?

While annotations already declare readOnly/open world/idempotent behavior, the description adds valuable non-obvious behavioral context: the tool switches between Data API v3 and yt-dlp depending on API key presence. This affects result consistency and feature availability, going beyond what annotations express. It also lists supported filters, giving a clearer operational picture.

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 extremely concise: two sentences front-loaded with the core purpose, followed by backend behavior and filter list. Every word earns its place, with no redundancy or 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?

Given the tool has 7 parameters, no output schema, and good annotations, the description covers purpose, backend behavior, and filters. However, it does not mention return format or pagination behavior, and the fallback mode's impact on filter availability is only indirectly indicated via the schema. Still, the description is largely complete for a search tool with rich schema.

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

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

Schema description coverage is 100%, and the schema already documents each parameter with descriptions and the '(API only)' caveat. The description's filter list (date range, channel, duration, order) maps to existing schema properties but adds no new syntax or semantic details beyond the structured definitions. 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 opens with 'Search YouTube videos,' a specific verb+resource that clearly distinguishes this from sibling tools like youtube_search_channels (for channels) and youtube_get_channel_videos (for videos from a channel). It also enumerates key filters, reinforcing scope.

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 usage context by noting the backend selection (API vs yt-dlp) based on YOUTUBE_API_KEY availability. However, it does not explicitly mention alternatives like youtube_search_channels or explain when not to use this tool, 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.

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

Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations: it explicitly requires YOUTUBE_API_KEY and discloses the output fields (subscriber counts, video counts, country). This is meaningful supplementary transparency, though it does not cover rate limits or error handling.

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 every clause adds value. No wasted words or redundancy with the schema/annotations.

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 5 parameters and no output schema, but annotations are rich. The description covers the primary purpose, key return fields, and an API requirement, which is adequate. However, it omits details about query formatting, filter interaction, or pagination behavior—though some of this lives in the schema. Not a fully comprehensive picture but above average.

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 parameters are documented. The description does not add extra semantic detail beyond the schema; it only paraphrases the query field as 'name/topic.' This aligns with the baseline 3 for high 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?

The description clearly states the tool searches YouTube channels by name or topic, with a specific verb ('Search') and resource ('YouTube channels'). It also lists returned fields (subscriber counts, video counts, country), which distinguishes it from sibling tools like youtube_get_channel_info and youtube_search.

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 usage for channel discovery but does not explicitly compare itself to alternatives like youtube_search (likely videos) or youtube_get_channel_info. The API key requirement is a useful prerequisite, but without exclusions or named alternatives, the guidance is only implied.

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