My TV Channel

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

Annotation Contradiction: The description states 'This ARCHIVES rather than destroys' and emphasizes that assets and schedule history are retained, directly contradicting the annotation destructiveHint=true. While the description itself is transparent, the contradiction forces a score of 1 per the rubric.

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 concise and front-loaded with the core action. Each of the five sentences adds critical information (action, retention, conflict behavior, idempotency, alternative tool), with no fluff or redundancy.

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

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

For a single-parameter tool with no output schema, the description covers all necessary behavioral context: what happens (archived, removed from listings), what is retained, when it fails (409), idempotency, and how it differs from a sibling. The annotation conflict is a separate issue but does not leave the description incomplete.

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 sole parameter channel_id is self-explanatory given the tool's purpose. Although schema coverage is 0%, the description's action 'Take a channel off the air' implies channel_id identifies the channel to archive, providing sufficient meaning beyond the bare integer type.

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

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

The description clearly states the action ('Take a channel off the air and out of every listing') and specifies the resource (a channel). It distinguishes itself from siblings by explicitly contrasting with delete_asset, 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?

The description provides explicit when-to-use guidance: 'This is the reversible way to take a channel down; delete_asset removes individual videos instead.' It also notes a precondition (refuses with 409 while transcodes are running), which is valuable usage context.

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 and idempotentHint=true, and the description aligns with this by framing the operation as a check. The description adds valuable context about the subdomain pattern and character constraints that the schema does not express.

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-loading the core purpose and then providing essential constraints. No filler or redundant phrasing.

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 read-only check tool, the description covers the purpose, constraints, and relationship to creation. It does not explicitly state the return type, but the name and wording make the boolean outcome unambiguous.

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 single parameter 'handle' is already described in the schema, but the description enriches it with format rules (3-63 chars, lowercase a-z, 0-9, hyphens) and explains its semantic role as the subdomain. This goes beyond the schema's basic example.

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 'check whether...is free' targeting the resource 'channel handle', and clarifies the handle's role as a subdomain. This clearly distinguishes it from sibling tools like create_channel or update_channel.

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 'before trying to create it' establishes the tool's intended position in the workflow relative to creation, though it doesn't explicitly name alternatives or exclusions. This provides clear context without formal when-not-to-use 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?

The description adds key behavioral context beyond annotations: a channel will not be live until it has at least 4 ready assets and 15 minutes of content. It also clarifies is_public's Discover visibility and tier availability. Annotations state readOnlyHint=false, which aligns with a create operation; no contradiction.

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 two-sentence description is succinct and front-loaded with the core purpose, followed by essential behavioral details. 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?

Given the tool's 10 parameters and no output schema, the description covers the most critical non-obvious behavior (live criteria) and is_public implications. However, it omits return value and any prerequisite like checking handle availability, but the annotation and schema handle much of the context.

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 description mentions is_public's behavior, but the schema already describes it. It does not explain undocumented parameters like tags, category, or description. With 70% schema coverage, the description adds marginal parameter value.

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 'Create a 24/7 linear TV channel' with a specific verb and resource. It clearly distinguishes from siblings like update_channel, archive_channel, list_channels, and get_channel.

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 that this tool creates a channel, and the name strongly implies when to use it. It does not explicitly mention alternatives or when not to use, but the context is unambiguous.

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 discloses critical behavioral details beyond the annotations: it is a soft delete ('asset is retained and stops being scheduled; it is not erased'), the schedule regenerates automatically, and the operation is idempotent. Although idempotentHint=true and destructiveHint=true are already in annotations, the description adds nuance about what 'destructive' means here and prevents misinterpretation.

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 yet information-dense. It front-loads the primary action, then adds essential details (soft delete, idempotency, retention, alternative) in three sentences. No word is wasted, and 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?

With one simple parameter and no output schema, the description covers all necessary facets: action, scope, side effects, idempotency, and distinction from the sibling archive_channel. It is fully adequate 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?

The schema has only one parameter (asset_id) with zero description coverage. The description does not explicitly name asset_id, but it repeatedly refers to 'a video' and 'the asset,' making the parameter's purpose unambiguous. For a single-param tool, this implicit meaning is sufficient, though explicit mention of asset_id would have been even clearer.

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: 'Remove a video from a channel.' It clearly identifies the action and scope. It also distinguishes itself from sibling tools by noting 'archive_channel takes a whole channel off the air,' so there is no ambiguity about what delete_asset does.

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

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

The description explicitly states when to use this tool versus archive_channel: 'Affects one video — archive_channel takes a whole channel off the air.' It also clarifies the behavior for scheduling ('stops being scheduled immediately') and idempotency, giving clear usage context.

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, covering the safety profile. The description adds behavioral context by specifying the data returned (quota limits, launchGaps) and cautions against assuming limits, which goes beyond annotations. It does not describe return format or pagination, but for a read-only tool with strong annotations this is acceptable.

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 'Start here.' Each clause adds specific, valuable information about the tool's output and recommended usage, with no redundant or filler 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?

Given the lack of an output schema, the description thoroughly enumerates the return values: account identity, subscription tier, limits, quota used/remaining, and channels with ready-asset counts and launchGaps. It also provides usage guidance. For a simple read-only tool, this is fully complete.

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

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

The tool has zero parameters and an empty input schema, so the baseline is 4. The description provides no parameter information because there are none to explain, and it introduces no ambiguity.

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 explicitly states the verb 'Returns' and enumerates specific account, subscription, quota, and channel information. This clearly distinguishes it from sibling tools like get_channel or list_channels, which focus on individual channels or schedules.

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 explicit usage context: 'Start here' and 'Call this before creating anything so you know the real limits for THIS account.' This tells the agent when to use it, but it does not name alternatives or explicitly state when not to use it.

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 value by disclosing that the response includes scheduleStatus, watchUrl, launchedAt, and isArchived, and by explaining the polling implication of scheduleStatus. It doesn't cover errors or edge cases, but with strong annotations this is sufficient.

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, front-loaded with the core purpose, followed by a compact list of relevant response fields and a practical hint. No wasted words; every part 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 get-by-id tool with one required parameter and no output schema, the description adequately covers the return fields and a key use case. The annotations fill in the safety and idempotency context, making the description complete 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?

Schema coverage is 100% (channel_id described as 'Channel id'), so the structured data already fully documents the parameter. The description adds no additional meaning beyond what the schema provides, matching the baseline of 3.

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 and resource ('Get one channel by id'), clearly distinguishing it from siblings like list_channels, create_channel, and update_channel. It also previews key return fields (scheduleStatus, watchUrl, launchedAt, isArchived), making 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?

Provides clear context by stating the polling use case ('poll this to confirm a channel has gone live'). It does not explicitly name alternatives or exclusions, but the singular focus on getting one channel by id implies when to use it over list_channels, and the polling hint gives concrete 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 read-only, idempotent, and non-destructive behavior, so the description is not required to repeat those. It adds a valuable behavioral detail beyond annotations: the return format difference (plain array vs object), which helps agents set expectations for output processing.

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: the first front-loads the primary purpose, and the second adds a critical caveat about return type. Every word earns its place, with no fluff or redundancy.

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

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

Given a simple one-parameter tool with strong annotations and no output schema, the description covers the essential context: what it reads, what it returns, and how it differs from siblings. It lacks detail on the structure of each entry in the array, but this is a minor gap for a common EPG concept.

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 never explicitly mentions channel_id or its role beyond the general 'channel's EPG'. While the parameter name is self-explanatory, the description leaves all parameter semantics to inference, failing to add value beyond the bare 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 a specific action ('Read') and resource ('channel's EPG') and explains what the EPG contains ('what is playing and what is coming up'). It also differentiates from siblings by explicitly noting the unique return type (plain array vs object), making 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 gives a clear sense of what the tool does but does not explicitly state when to use it over alternatives like get_schedule_rules or get_channel. The note about returning an array hints at a distinguishing feature but stops short of providing explicit usage guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about what specifically is returned (schedule rules, scheduling mode, timezone), going beyond the bare 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?

A single, clear sentence that is front-loaded with the verb, resource, and key details. No wasted words or redundancy.

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

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

For a simple read-only tool with strong annotations, the description adequately enumerates what is returned. There is no output schema, but the description's list (rules, mode, timezone) is sufficient for an agent to know what to expect.

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 schema description coverage at 0%, the description should compensate, but it barely adds meaning beyond the schema: 'the channel's' confirms channel_id identifies a channel, which is already obvious from the parameter name. For a single integer parameter, this is adequate but minimal.

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 'Read' and clearly identifies the resource as 'the channel's declarative schedule rules (fixed time slots and dayparts), plus its scheduling mode and timezone.' This distinguishes it from the sibling tool get_schedule, which presumably returns the actual generated schedule.

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 clear it reads declarative rules, which implies when to use it versus get_schedule. However, it does not explicitly state 'use this for rules, not generated schedule' or mention any alternatives/exclusions, so it lacks explicit 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?

Goes beyond the readOnly/idempotent annotations by disclosing the uploadStatus state machine, the meetsLaunchRequirements threshold (4+ ready assets and 900+ seconds), and transcoding speed. This gives the agent critical operational context for interpreting responses and setting expectations.

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. The description is front-loaded with the core purpose, then adds parameter guidance, state behavior, and polling cadence without any 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?

Covers the key return concepts (uploadStatus values and the summary threshold) despite lacking an output schema. It does not describe the full JSON shape or error cases, but for a polling tool it provides enough to use correctly. A slightly more explicit response structure would make it 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 has no descriptions and 0% coverage, but the description explains both parameters well: channel_id returns status for all its videos, asset_id for a single asset. It also implies mutual exclusivity with 'either', compensating fully for the schema 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 opens with a specific verb+resource: 'Poll transcode progress.' It clearly distinguishes this from sibling tools like retry_transcode by focusing on monitoring rather than initiating or retrying. The two modes (by channel or asset) are also clearly stated.

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 clear context on when to use the tool: poll progress every 30-60s and expect transcoding to take roughly real-time/4. It does not explicitly mention alternatives or exclusion criteria, but the polling guidance is strong and implies this is for monitoring only.

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 annotations (readOnlyHint false, openWorldHint true), the description explains the asynchronous pipeline (downloading -> pending -> transcoding -> ready), quota impact, URL constraints, and deduplication behavior on re-submission. This adds significant context not present in 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 longer than minimal but every sentence carries useful information. It is front-loaded with the purpose and uses emphasis to highlight key constraints. Slightly verbose due to multiple clauses, but none are wasted.

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

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

The tool has no output schema, and the description covers most operational aspects: return timing, asset states, quota, URL constraints, and sibling alternatives. It doesn't specify the exact return payload, but the async behavior is clearly communicated, making it nearly complete for a tool of this 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 coverage is only 40%, and the description compensates well for the critical 'url' parameter with detailed format and accessibility requirements. It also adds behavioral guidance for 'weight' (set here instead of after). However, 'title' and 'tags' remain unexplained, leaving some 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 'Add a video to a channel from a direct media URL' with a specific verb and resource. It distinguishes itself from the sibling import_youtube_video by specifying direct media URL and excluding YouTube/Vimeo watch pages, and declares itself the main way to add content.

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 provides when to use (direct media URL) and when not (local bytes, watch pages, login-protected URL). It also references an alternative tool for setting weight (see set_asset_weight) and explains the need to host local files externally.

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 discloses the ownership verification mechanism (tag), the 403 error behavior, the fact that the agent cannot bypass it, and daily/quota limits. These go beyond the annotations and provide critical behavioral details about failure modes and constraints. 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 well-structured, starting with the core purpose, then the ownership proof steps, constraints, and limits. Each paragraph is necessary and no sentence is wasted. It is front-loaded with the most important 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?

The description covers the tool's purpose, prerequisites (ownership tag), constraints (video types, URL formats), limitations (10/day, weekly quota), and the error handling (403 with tag string). Given no output schema exists, the description provides sufficient context for an agent to use 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 covers only 2 of 5 parameters (url and title), and the description does not explain the meanings of tags, weight, or channel_id. It clarifies the ownership tag process but not how the API parameters map to it. Thus the description fails to compensate for the low 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 imports a YouTube video that the owner uploaded themselves, distinguishing it from generic URL imports. The verb 'Import' is specific to a resource, and the ownership constraint is immediately 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 explicitly states when to use the tool (owner's own videos), when not to use it (others' videos, live/private/age-restricted/playlists/channel URLs), and includes usage limits. However, it does not explicitly name alternative sibling tools like import_video_from_url, so it loses a point for missing explicit alternative 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no extra behavioral context such as return format, pagination, ordering, or permission requirements. It merely restates the basic action, which does not go beyond what annotations and schema already imply.

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, efficient sentence with no redundant wording. It is appropriately concise and front-loaded, stating the core action immediately. It lacks additional structural elements like examples, but for such a simple tool, the brevity is not a flaw.

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 and the presence of annotations, the description is still incomplete. It does not mention the return value (no output schema exists), pagination, or how 'videos' relates to the tool name 'list_assets' (assets could be a broader category). Sibling tools like delete_asset and set_asset_weight suggest assets are videos, but this is not explicitly stated. The lack of usage guidance further reduces completeness.

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 for explaining channel_id. The phrase 'on a channel' gives a minimal hint that channel_id identifies the channel, but it does not clarify the nature of the ID (e.g., numeric, required format) or how to obtain it. For a simple integer parameter, this is barely adequate.

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 'List the videos on a channel' uses a specific verb ('List') and resource ('videos'/'channel'), clearly distinguishing it from sibling tools like list_channels (which lists channels) and get_channel (which fetches a single channel's details). The phrase 'on a channel' also clarifies the scoping role of the channel_id parameter.

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

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

No guidance is provided regarding when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or how this differs from list_channels or get_channel. The description simply states the action without contextual cues.

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 the scope ('owned by this account') but does not disclose additional behavioral traits such as pagination, ordering, or whether the list is exhaustive. This is acceptable for a simple read-only list operation but adds limited value 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise and easy to parse.

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 parameters, no output schema, and strong annotations, the description is sufficient. It states the resource and scope, and the read-only nature is already conveyed by annotations. The agent can confidently invoke this tool without additional expectations.

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

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

The tool has 0 parameters, making the schema fully covered by default. The description adds no parameter details, but the baseline for 0-param tools is 4, and there is nothing to explain.

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

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

The description clearly states the action ('List'), the resource ('channels'), and the scope ('owned by this account'). This distinguishes it from sibling tools like get_channel (singular) and create_channel/update_channel/archive_channel (mutations).

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 retrieving all channels belonging to the account, which gives context. However, it does not explicitly state when to use this vs. alternatives like get_channel for a specific channel, nor does it mention exclusions or limitations.

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 (destructiveHint: true, idempotentHint: false), the description adds critical behavioral details: throttling limits (one call per channel per 5 minutes, 429 with Retry-After), the requirement that the channel must be live, and the timing effect of not calling it (change will not air until hourly cron). These are not available in annotations and enrich the agent's understanding of consequences.

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 concise: three sentences that lead with the action, then usage context, then constraints. No redundant or filler content; every sentence contributes to the agent's understanding.

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 single-parameter action tool without an output schema, the description covers the core context: purpose, when to use, throttling, and prerequisites. It does not describe the success response or side effects beyond rebuilding, but given the simplicity, this is a minor omission.

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 has only one parameter (channel_id, integer, required) with no description coverage. The tool description mentions 'channel' but does not explicitly explain the parameter semantics or constraints. However, the purpose is clear from context: channel_id identifies the channel to rebuild. This is sufficient but adds little 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 clearly states the tool's function: 'Rebuild the channel's schedule now using the current weights.' It uses a specific verb (rebuild) and resource (channel's schedule), and distinguishes from sibling tools like get_schedule (read-only) and validate_schedule_rules (validation). The context of 'after changing weights' further clarifies its 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 explicitly states when to use the tool: 'Call this after changing weights on a channel that is ALREADY live, otherwise the change will not air until the hourly cron.' It also provides the alternative of waiting for the cron, and notes throttling (429 with Retry-After) and prerequisites (launch requirements). This gives a clear usage policy.

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 indicate this is a non-read-only, non-idempotent mutation, and the description adds the key constraint that it only works on failed-state assets. It does not disclose potential side effects (e.g., whether a successful retry clears errors, whether it resets other fields, or required permissions), so transparency is adequate but not rich.

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 with no wasted words. It front-loads the action and includes the necessary constraint, making it easy to parse quickly.

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

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

For a simple one-parameter tool with no output schema and minimal annotations, the description covers the core purpose and a key precondition. It lacks details about error conditions or return values, but these are less critical given the tool's simplicity and the availability of sibling status-checking tools.

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 has 0% description coverage for the single integer parameter asset_id. The description implies that asset_id identifies the video to be requeued, but it never explicitly states this connection. Since there is only one simple parameter, the inference is straightforward, but the description does not fully compensate for the schema 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 uses the specific verb 're-queue' and identifies the resource as 'a video whose transcode failed', clearly distinguishing it from sibling tools like get_transcode_status (status check) and delete_asset. The added condition 'Only works on assets in a failed state' further clarifies the tool's 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 context that the tool applies only to assets in a failed transcode state, implying it should be used when a transcode has failed and needs to be retried. However, it does not explicitly name alternatives or state when not to use it beyond that condition, so it stops short of a full 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 significant behavioral context beyond the annotations: weight 0 removes the asset from rotation, weights are relative, and the critical ordering effect on schedule generation. It also clarifies the idempotent nature (setting the same weight is safe) and does not contradict the annotations (readOnlyHint=false, destructiveHint=false).

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 moderately detailed but every sentence adds value, especially the ordering caveat which is critical for correct use. The use of 'IMPORTANT ORDERING' highlights a key behavioral constraint. It is well-structured and avoids redundancy.

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

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

The description covers the essential behavioral context, parameter semantics, and relationship to schedule regeneration. It does not mention return values, but since there is no output schema and this is a mutation tool, that is not a major gap. Sibling names like regenerate_schedule are referenced, which helps contextual understanding.

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 provides description only for tags (25% coverage), leaving weight, title, and asset_id without descriptions. The description compensates by explaining weight's range, default, and special behavior (0 removes from rotation), and mentions title/tags as optional. However, it does not provide additional detail on asset_id or title beyond the property names, so a small gap remains.

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: 'Change how often a video plays (weight 0-10, default 5; 0 removes it from rotation entirely), and optionally its title or tags.' This is a specific verb (change) with a clear resource (video weight, title, tags), and it distinguishes itself from siblings like set_schedule_rules or regenerate_schedule by focusing on per-asset settings.

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 provides explicit timing guidance: 'weights only affect what actually airs when the schedule is (re)generated' and mentions the alternative action 'call regenerate_schedule afterwards'. It also explains the relative nature of weights and the default value, giving the agent clear context for when to use this tool vs 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?

The description richly discloses behavioral traits beyond annotations: it replaces the whole ruleset, slots start on-or-after time and never cut running programs, timezone defaults to UTC, and weight_multiplier 0 removes assets. These details are not in the annotations and significantly aid correct use.

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?

Although long, every sentence adds value: examples, edge cases, and explanations are all relevant. The structure (overview, replacement warning, rule shapes, bitmask, special behaviors) is logical and front-loaded with the core purpose.

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 complexity (nested rules, multiple selector types, bitmask, block behavior), the description covers all necessary operational details, including edge cases like weight_multiplier 0 and slot timing. No output schema exists, but the description adequately addresses what the tool does and how to use it.

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 provides basic descriptions, but the description goes far beyond with rule shapes, days_mask bitmask semantics (bit0=Mon, 127=daily), end_time behavior for blocks, playlist order, and timezone significance. It fully compensates for the 67% schema coverage and adds crucial meaning.

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

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

The description states the tool gives a channel a durable schedule with fixed slots and dayparts, which is specific and distinguishes it from related tools like validate_schedule_rules and get_schedule_rules. It clearly names the resource (channel) and the action (set rules).

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 validate first with validate_schedule_rules and explains the tool replaces the entire ruleset, including how to clear rules (empty array). It also advises setting timezone, providing clear when-to-use guidance and 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?

Annotations already indicate the tool is not read-only, is idempotent, and is not destructive. The description adds the partial-update behavior ('Only send the fields you are changing'), which goes beyond the annotations and clarifies how the tool behaves for unchanged 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?

The description is a single, information-dense sentence. It leads with the action and resource, lists the fields, and ends with the critical usage instruction. 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?

For a tool with 13 parameters and no output schema, the description is adequate but thin. It doesn't mention response format, required channel_id, dependencies among fields (e.g., chat_platform nuances), or any edge cases. The guidance to send only changed fields is useful, but more context on required prerequisites or side effects would make it 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 description lists key fields (name, description, visibility, category, language, age rating, community chat link), but the schema has 13 parameters and only 46% have descriptions. The description partially compensates by identifying common fields, yet omits several parameters (e.g., keywords, show_schedule, chat_server_id) and doesn't explain their semantics.

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 action ('Update an existing channel') and enumerates the primary fields it covers. This distinguishes it from sibling tools like create_channel, get_channel, and archive_channel, making its 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 conveys that this is for modifying an existing channel and provides the pragmatic guidance to send only changed fields (PATCH-style). It implies the alternative is creating a new channel, but it doesn't explicitly name create_channel or other 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?

Annotations already declare readOnly/idempotent/destructive hints, and the description adds that it saves nothing, returns a preview grid, works on any tier, and explains wall-clock/daypart semantics that make results hard to predict. This goes beyond annotations to disclose key behavioral nuances.

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?

Four sentences each carry meaningful content: purpose, return structure, usage context, and tier gating. It is dense but not bloated, though slightly longer than strictly necessary.

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 validation tool, it thoroughly covers return shape, behavior, alternative usage, tier gating, and why a dry-run is needed. The absence of an output schema is compensated by describing the return structure and preview contents.

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 75% of parameters with descriptions, including the rules parameter noted as 'Same shape as set_schedule_rules'. The description repeats this crossover but adds no additional parameter-level details beyond what the schema already provides, so it earns a solid middle score.

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 it is a DRY-RUN of a ruleset, with an explicit verb and resource. It differentiates itself from set_schedule_rules, its direct sibling, by positioning itself as the dry-run counterpart and describing the return value.

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 'Intended as the dry run for set_schedule_rules' and notes that unlike set_schedule_rules it is not tier-gated, giving clear when-to-use and alternative context. It also explains why the dry-run is necessary due to the unpredictable airing behavior.

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