My TV Channel

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

The description directly contradicts the annotations. It states 'This ARCHIVES rather than destroys' and 'it can be restored,' while the annotations include destructiveHint=true. This is a serious inconsistency that undermines trust in the tool's behavior. Even though the description adds useful context about error handling and reversibility, the contradiction forces a score of 1.

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 and front-loaded with the primary action. It includes all critical caveats (archival vs destruction, 409 refusal, idempotence, alternative) with zero wasted words. The structure is ideal.

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 the action, reversibility, error behavior, and the alternative. It lacks details on permissions or return values, but those are not essential given the tool's simplicity. The annotation contradiction is the primary missing element, but that is already accounted for in behavioral transparency. Overall, the description is quite 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 input schema has 0% description coverage, so the description must compensate. However, it does not explicitly explain channel_id beyond what the parameter name implies. The tool's action makes it obvious that channel_id identifies the channel to archive, but no additional constraints, formats, or edge cases are mentioned. This is a minor but noticeable gap.

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

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

The description clearly states the tool's action: 'Take a channel off the air and out of every listing.' It uses a specific verb ('archive') with a resource ('channel') and distinguishes itself from the sibling tool delete_asset, which removes individual videos instead. This is a precise purpose statement.

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 names an alternative (delete_asset) and positions archive_channel as the reversible way to take a channel down. It also provides a concrete precondition/error condition: refuses with a 409 while transcodes are running. This offers clear when-to-use and 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?

Annotations already mark this as read-only, idempotent, and non-destructive, covering the safety profile. The description adds useful context: the handle becomes a subdomain and the character rules (3-63 chars, lowercase, hyphens). It doesn't detail the return format, but for a check operation this is a minor omission given annotation coverage.

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

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

The description is two concise sentences, front-loaded with the primary action and followed by relevant constraints. 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 simple one-parameter tool, the description covers usage timing, validation rules, and the subdomain format. The absence of an output schema for a check tool means the return value (e.g., boolean) is not explicitly stated, which is a slight gap but not critical given the simplicity.

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 single parameter with an example. The tool description adds extra semantics by explaining the subdomain format and charset constraints, which are not present in the schema, thus enriching parameter 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 uses a specific verb 'Check' and clearly identifies the resource as 'channel handle availability'. It distinguishes itself from sibling tools like create_channel by focusing on the pre-check action.

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' provides clear context that this should be used prior to create_channel. It doesn't explicitly name alternatives or exclusions, but the usage timing is obvious from the 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?

The description discloses important behavioral traits beyond the annotations: the channel will not be live immediately but automatically goes live after having at least 4 ready assets and 15 minutes of total content. It also explains that is_public affects Discover visibility and tier availability. This provides operational context the annotations do not cover.

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 the core purpose front-loaded. Each sentence adds unique value: the action, the activation condition, and the is_public effect. No redundant or filler wording is present.

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 explains the activation mechanism and is_public but omits any mention of the response format (no output schema exists) and does not cover the full parameter set or workflow. Given the tool's complexity (10 parameters, nested objects), the description is helpful but not fully complete for an agent.

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 70% schema coverage, most parameters already have descriptions. The description adds meaning for is_public (Discover listing and tier reach) and the overall live condition, but it does not explain the other seven parameters beyond what the schema 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 states 'Create a 24/7 linear TV channel' with a specific verb and resource, clearly distinguishing it from update_channel and archive_channel. The added detail about the channel not being live yet further clarifies the tool's scope, though it does not explicitly name sibling alternatives.

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 on when to use this tool versus update_channel or other channel-management tools. The only usage-related hint is that the channel becomes live after meeting content thresholds, which is a behavioral note rather than a comparative usage guideline.

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?

Although annotations already include idempotentHint and destructiveHint, the description adds meaningful behavioral context: 'Soft delete — it stops being scheduled immediately and the schedule regenerates automatically,' 'The asset is retained and stops being scheduled; it is not erased,' and 'Affects one video.' These details clarify what a destructive hint means in practice (not permanent erasure) and what the side effects are, going well beyond the structured annotations.

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

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

The description is three sentences, with the main action front-loaded. Each sentence adds value: the operation, the soft-delete behavior and side effects, and the scope contrast with archive_channel. There is no redundancy or unnecessary detail.

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 one parameter, no output schema, and annotations, the description covers the key aspects: what is affected (one video), the immediate effect (stops scheduling), the subsequent behavior (schedule regenerates), the idempotency and retention, and the alternative when a whole channel needs removal. This is complete for the tool's complexity.

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

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

The input schema only defines asset_id as an integer with no description, and schema description coverage is 0%. The description does not explicitly explain asset_id, but the tool name and 'Remove a video from a channel' make it evident that asset_id identifies the video to be removed. This partial compensation is enough for a single obvious parameter, but not fully explicit.

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 'Remove a video from a channel,' which is a specific verb+resource construction that clearly states what the tool does. It also differentiates itself from the sibling tool archive_channel by noting that 'archive_channel takes a whole channel off the air' and that this tool 'Affects one video.' This makes the 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 explicitly contrasts this tool with archive_channel, telling the agent when to use delete_asset (for a single video) versus an alternative (for a whole channel). It also provides context that this is a soft delete that immediately stops scheduling and regenerates the schedule, which guides selection for use cases where retention of the asset is desired.

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, so the safety profile is clear. The description adds valuable behavioral context by enumerating specific return data (quota remaining, launchGaps) and emphasizing per-account accuracy. No contradictions 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: the first enumerates return values, the second gives usage guidance. It is front-loaded with 'Start here' and contains no filler or redundant information. 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 no-parameter, no-output-schema tool, the description provides a thorough account of what to expect: account identity, tier, limits, quota, channels, and launch gaps. It also includes usage context, making it complete for an agent to decide when and how to invoke it. No further details seem necessary.

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, so schema coverage is 100% by definition. The baseline for zero-param tools is 4, and the description appropriately focuses on return values rather than parameter details. No additional parameter semantics are needed.

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

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

The description clearly states what the tool does: it returns account identity, subscription tier, limits, quota usage, and channel launch status. It uses a specific verb ('returns') and resource ('account status'), and the level of detail distinguishes it from any sibling tool. No other tool covers account-level information.

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 instructs to 'Start here' and to call this tool 'before creating anything' to know real limits for the account. This provides clear when-to-use guidance and implicitly discourages assuming limits without checking. It effectively positions this tool as the first step in a workflow.

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, covering the safety profile. The description adds behavioral context beyond the annotations by listing specific return fields (scheduleStatus, watchUrl, launchedAt, isArchived) and indicating that the status can change, making it suitable for polling. 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 concise and well-structured: it front-loads the core purpose in the first sentence and adds valuable detail in the second. No redundant information or filler. Every sentence earns its place.

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

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

For a simple single-channel getter with one parameter, the description is quite complete. It explains the primary use case, key return fields, and a monitoring pattern via polling. Annotations cover safety, and there's no output schema requiring explanation. It does not mention error behavior for missing channels, but that's a minor gap 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?

The input schema has a single parameter 'channel_id' with a description 'Channel id', and schema coverage is 100%. The tool description does not add additional meaning for this parameter. Since the schema already fully explains the parameter, 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's function: 'Get one channel by id.' This uses a specific verb (Get), identifies the resource (channel), and specifies the scope (by id). It distinguishes from sibling tools like list_channels by focusing on a single channel retrieval.

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

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

The description provides a clear use context: 'poll this to confirm a channel has gone live.' This indicates when to use the tool, though it does not explicitly mention alternatives or exclusions. The polling guidance is a strong usage hint, but it doesn't say 'use list_channels for multiple channels' or similar.

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, and non-destructive. The description adds valuable behavioral context by stating it returns a plain array unlike other tools, which is beyond the annotation coverage. No contradictions.

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: first states the tool's main function, second gives a crucial behavioral distinction. No fluff, information is front-loaded and easily digestible.

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 low complexity (single parameter, no output schema), the description covers the essential purpose and return format. It could elaborate on entry structure, but annotations and the note about array vs object provide sufficient completeness for effective selection and invocation.

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

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

Schema has no description for channel_id, and coverage is 0%. The description implies channel_id is the channel by saying 'the channel's EPG', but it does not clarify the type or any constraints beyond the schema. It partially compensates for the lack of schema descriptions but could be more explicit.

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 the tool reads the channel's EPG (what is playing/coming up). The description uses a specific verb ('Read') and resource ('EPG'), and the note about returning an array distinguishes it from siblings like get_schedule_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?

Provides clear context for when to use: to read EPG content. It contrasts return shape with other tools but does not explicitly name alternatives or state when not to use it, leaving some room for inference.

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

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

Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds what is read (rules, mode, timezone) but does not reveal additional behavioral traits like error conditions, rate limits, or return format. Since annotations carry the main safety burden, the description's added context is modest but not contradictory.

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 immediately states the purpose and includes parenthetical examples. Every word carries meaning, 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?

The tool is simple: one required parameter, no output schema, and strong annotations. The description sufficiently conveys what the read returns and implies the channel context. It does not describe the exact output structure, but given the low complexity and existing annotations, this is an acceptable level of 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?

The input schema defines channel_id with only type integer and required status, and schema_description_coverage is 0%. The description does not mention channel_id at all, so it adds no meaning beyond the schema. Although the parameter is self-explanatory given the tool name, the description fails to compensate for the lack of schema-level documentation.

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

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

The description uses a specific verb 'Read' and clearly identifies the resource: 'declarative schedule rules (fixed time slots and dayparts), plus its scheduling mode and timezone.' It distinguishes this from sibling tools like get_schedule (which likely retrieves the actual schedule) and set_schedule_rules (which writes).

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

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

The description clearly implies a read operation on schedule rules, but it does not explicitly recommend when to use this tool over alternatives such as get_schedule or validate_schedule_rules. There are no exclusions or alternative names mentioned, leaving the usage context 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 readOnlyHint and idempotentHint annotations, the description discloses key behavioral details: the polling cadence, the state machine (downloading -> pending -> transcoding -> ready), and the specific condition for meetsLaunchRequirements (4+ ready assets and 900+ seconds). These are non-obvious runtime behaviors that materially affect how the tool should be used.

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 dense but not bloated. It front-loads the core action, then proceeds through parameters, state details, and polling advice. Each sentence earns its place, though the sentence about meetsLaunchRequirements is somewhat long and could be split for readability.

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 there is no output schema, the description does an excellent job of explaining what the caller will see: per-asset uploadStatus and the summary field meetsLaunchRequirements with its specific threshold. Combined with parameter semantics and polling guidance, the description leaves no critical gap for a status-checking 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 provides no descriptions for asset_id or channel_id (0% coverage). The description explicitly differentiates them: channel_id returns all videos for that channel, asset_id returns a single asset. This is exactly the kind of meaning the schema lacks, fully compensating for the schema's silence.

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

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

The description opens with the specific verb 'Poll' and the resource 'transcode progress', making the tool's function immediately clear. It further specifies the two input modes (channel_id vs. asset_id), which distinguishes it from sibling tools like retry_transcode or import_video_from_url.

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 usage context by explaining when to poll ('Poll every 30-60s') and the expected duration ('transcoding takes roughly real-time/4'). It does not explicitly mention alternatives or exclusion cases, but the purpose is unambiguous enough that an agent would know this is for status checks rather than actions like retry.

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 is rich in behavioral detail (server downloads, immediate return, asset lifecycle, quota, idempotent re-submission), but it contradicts the idempotentHint annotation. The annotation says idempotentHint: false, yet the description states 'Re-submitting the same URL to the same channel returns the original asset instead of importing twice,' which is idempotent behavior. This direct contradiction triggers a score of 1 per the rules.

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 dense but every sentence provides necessary constraints or behavioral context. It is front-loaded with purpose, then details usage limits, process, quota, and idempotency. No wasted words; structure is logical and appropriately sized for the tool's complexity.

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 and lack of output schema, the description covers return behavior ('Returns immediately; asset then goes downloading -> pending -> transcoding -> ready'), quota impact, and edge cases like re-submission. It also references set_asset_weight for weight adjustments, providing a complete picture for effective use.

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 adds significant meaning for the url parameter by detailing acceptable formats and exclusions, far beyond the schema's 'Direct, public media URL.' It also clarifies the weight parameter's purpose and timing ('Set it here rather than after'). However, channel_id, tags, and title remain undocumented beyond their schema entries, and schema coverage is only 40%, so the description does not fully compensate for all parameters.

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

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

The description clearly states the tool's function: 'Add a video to a channel from a direct media URL.' It also specifies this is the main way to add content over MCP, distinguishing it from local file uploads and other tools. The verb and resource are specific, and the mention of 'not a YouTube/Vimeo watch page' helps differentiate from import_youtube_video.

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

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

The description provides explicit when-to-use and when-not-to-use guidance. It states the URL must be a direct, public, unauthenticated link to specific formats, not a web page, not behind a login, and not a YouTube/Vimeo watch page. It also advises on handling local files and mentions the quota. This clearly defines the tool's intended use versus alternatives.

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

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

The description discloses the ownership verification process, the 403 error containing the tag string, the impossibility of bypassing step 2, and the daily quota. This adds substantial context beyond the annotations (readOnly=false, openWorld=true, etc.) and does not contradict them.

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

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

Although lengthy, every sentence provides essential procedural or restriction information, organized in clear numbered steps. There is 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?

The description covers usage, restrictions, error behavior, and quota, making it self-contained. With no output schema, it leads the agent through potential failure modes and prerequisites, and it is sufficiently complete for a complex 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 only 40% (url and weight have descriptions). The description does not explain the semantics of tags, title, weight, or channel_id. It mentions URL restrictions but those are already in the schema, so it fails to compensate for the low 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 and explicitly restricts it to videos the OWNER uploaded themselves. This specific verb+resource+scope distinguishes it from sibling tools like import_video_from_url.

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 when/when-not guidance: use only for owner's own videos, and it will not work for anyone else's. The tag verification steps and restrictions (public, no live/private, rate limits) further clarify appropriate usage.

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 non-destructive behavior. The description adds that it returns videos (rather than broader assets) and scopes to a channel, but does not mention pagination, ordering, or response structure beyond the 'videos' label. This is some added context 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?

A single clear sentence, front-loaded with the verb and resource. No redundant words or filler. It is appropriately concise for the tool's simplicity.

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 only one parameter and strong annotations, the description is minimally viable. It does not describe the return format (no output schema), potential pagination, or what 'videos' entails (e.g., metadata fields). However, for a basic list operation, the description provides enough to understand the core purpose.

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

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

Schema description coverage is 0%, so the description must explain the channel_id parameter. It only says 'on a channel', which implies channel_id identifies the channel, but it does not specify what the integer represents (e.g., internal ID, YouTube channel ID) or how to obtain it. Minimal compensation for the missing schema documentation.

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

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

The description uses a specific verb ('List') and resource ('the videos on a channel'), clearly distinguishing it from sibling tools like list_channels or get_channel. It unambiguously states the function.

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 you need to list videos for a channel) but does not explicitly mention when not to use it or provide alternatives. No exclusions or context comparing it to sibling tools, so it is borderline between implied and clear 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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the ownership scope (owned by this account), which is useful context beyond the structured metadata.

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 with no filler or redundancy. Every word contributes to the meaning.

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 is simple (no parameters, no output schema), and the description fully conveys its purpose and scope. There is no missing information that would impair correct invocation.

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

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

There are no parameters, and schema coverage is 100%. The description does not need to explain parameter semantics. Baseline for zero-parameter tools is 4.

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), resource (channels), and scope (owned by this account). It is specific enough to distinguish from sibling tools like get_channel (singular) and list_assets.

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 context implies usage for retrieving all channels for the current account, with no exclusions or alternatives mentioned. Since it is a basic list operation, the absence of explicit when-not or alternative guidance is not a significant gap.

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 concrete behavioral details beyond the annotations: a 5-minute throttle, a 429 response with Retry-After, and the requirement that the channel must meet launch requirements. It also implies that changes are not automatically airing immediately without this call, which explains the tool's effect. No contradiction with the destructiveHint or non-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?

Three sentences, each earning its place: purpose, when-to-use, and behavioral constraints. No redundant phrasing or filler. The description is front-loaded with the core 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?

Despite lacking an output schema, the description covers the essential operational context: what triggers it, how it differs from the cron, rate limits, errors, and requirements. This is sufficient for an agent to decide when and how to invoke the tool, and no critical information for a mutation is missing.

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

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

The only parameter, channel_id, is clear from the description's repeated reference to 'the channel', and the schema names it explicitly. However, the description does not formally describe the parameter type or explain what should be passed beyond the name, leaving a slight gap. Given the single self-explanatory parameter, the description adds enough contextual meaning to merit a strong 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 opens with 'Rebuild the channel's schedule now using the current weights', clearly stating the verb, resource, and immediate action. It distinguishes itself from sibling tools like get_schedule (read) and set_schedule_rules (configure) by focusing on manual regeneration. The specificity of 'now' and 'current weights' leaves no ambiguity.

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

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

Explicitly instructs when to call: 'Call this after changing weights on a channel that is ALREADY live, otherwise the change will not air until the hourly cron.' It also names the alternative (waiting for cron) and notes throttling and prerequisites. This is exactly the kind of when-to-use vs. wait guidance that helps an agent decide.

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 non-read-only, non-idempotent, non-destructive behavior. The description adds the state constraint (failed assets) and the action of re-queuing, which is useful. It doesn't disclose potential error behaviors or side effects, but the annotation coverage lowers the burden.

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 that front-load the action and the key constraint. Every word earns its place with no 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 one-parameter mutation tool with no output schema, the description provides the essential purpose and a clear precondition (failed state). It adequately covers what an agent needs to decide whether to invoke it, though it could mention what happens if the asset isn't in a failed state.

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 no description for asset_id (0% coverage), but the description mentions 'a video' and 'assets,' which helps infer that asset_id identifies the video to retry. This is minimal but sufficient for a single obvious parameter.

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 'Re-queue' and identifies the resource as 'a video whose transcode failed.' It clearly distinguishes the tool from siblings like get_transcode_status or delete_asset by focusing on retrying failed transcodes.

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 clearly that the tool 'Only works on assets in a failed state,' which sets a precondition for use. While it doesn't explicitly name alternatives or exclusions, the constraint implies when to use it and when not to.

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 critical ordering constraint: weights set after schedule generation are stored but do not air. It also explains that weights are relative, which is non-obvious behavioral context beyond the annotations. This adds significant transparency about side effects and timing.

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

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

The description is front-loaded with the main purpose, followed by a clearly marked 'IMPORTANT ORDERING' note. Every sentence provides crucial information without filler. It's concise and well-structured for quick 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?

Despite no output schema and limited sibling context, the description covers the main functionality, the key timing pitfall, and the relative weight behavior. It gives enough information for an agent to use the tool correctly, including how to recover from the ordering gotcha. No significant gaps remain.

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 explains the weight parameter in detail (range, default, 0 meaning, relative nature), which is not fully covered by the schema. It also mentions title and tags as optional. However, it doesn't add detail for the tags parameter's special sequencing behavior (already in schema) or title semantics, so it doesn't fully compensate for the low schema coverage, but weight is well covered.

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.' It uses specific verbs and resources, and distinguishes from sibling tools like regenerate_schedule or set_schedule_rules by focusing on per-asset weight and metadata updates.

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 guidance on when to use the tool: weights only affect airtime when the schedule is (re)generated, and it tells the user to either set weight at import time or call regenerate_schedule afterwards. This directly addresses alternative workflows and prevents misuse.

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 goes far beyond annotations. It explains the durable re-honoring on EVERY rebuild, the replacement semantics, the empty-array removal, slot start behavior ('ON-OR-AFTER', never cutting short), block behavior via end_time, playlist ordering, and timezone defaulting to UTC. These are non-obvious behavioral traits that the annotations (destructiveHint, idempotentHint) do not fully capture.

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 long but every sentence carries critical operational information. It is structurally organized: intro, replacement warning, validation note, rule shape definitions, bitmask explanation, edge-case behaviors. There is no fluff or redundancy; the density is justified by the tool's complexity.

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 3 parameters and no output schema, the description covers all necessary invocation details: required params, full rule object semantics, days_mask encoding, timezone necessity, and behavioral edge cases. An agent has enough to correctly construct a call without guessing, and the absence of an output schema is acceptable since the tool's result is a straightforward success/error.

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 adds rich meaning to every parameter beyond the schema. It details the two rule shapes with inline examples, defines days_mask as a bitmask with concrete values (127=daily, 31=Mon-Fri, 96=weekend), explains end_time's role in creating blocks, describes selector_type 'playlist' as ordered, and clarifies weight_multiplier 0 behavior. This compensates for the 67% schema coverage and is genuinely instructive.

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

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

The description opens with a clear verb+resource: 'Give the channel a durable schedule' with concrete examples ('news at 18:00', 'no kids content after 22:00'). It immediately differentiates from siblings like get_schedule_rules (read), validate_schedule_rules (check), and regenerate_schedule (rebuild), while stating the REPLACES behavior that defines this setter's unique role.

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

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

Explicit prerequisites and workflow are provided: 'Validate first with validate_schedule_rules', 'Pro tier or higher', and the warning that sending an empty array clears all rules. It also tells the agent exactly how to frame the call ('send every rule you want, not just new ones') and when this is beneficial ('set them once instead of babysitting the grid').

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 readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the tool is known to be a non-destructive, idempotent write. The description adds the partial-update behavior, which is useful, but does not mention side effects, permissions, or handling of omitted fields beyond the implicit 'only send changed 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, concise sentence that front-loads the core action and key constraint. It is not verbose, though the list of fields could be more precise and aligned with schema names.

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 (13 parameters) and lack of an output schema, the description is insufficient. It does not explain what the tool returns, whether omitted fields retain their previous values (though implied), or any prerequisites or side effects. The partial-update guidance is helpful but incomplete for such a broad update 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 only 46%, so the description needs to compensate for undocumented parameters. However, it omits several parameters (keywords, show_schedule, allow_offline_download, chat_server_id, chat_channel_id) and uses vague terms like 'visibility' instead of is_public and 'community chat link' instead of chat_platform/server/channel. It does not provide enough clarity to make all 13 parameters understandable.

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

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

The description clearly states the verb 'Update' and the resource 'existing channel', and lists specific updatable fields (name, description, visibility, category, language, age rating, community chat link), which distinguishes it from create_channel and archive_channel. It is specific and 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 instruction 'Only send the fields you are changing' is a useful usage guideline for how to call the tool, but it does not explicitly state when to use this tool versus alternatives like create_channel or archive_channel. The usage context is implied by 'existing channel'.

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 (readOnly, idempotent, non-destructive), the description adds meaningful behavioral detail: 'Saves nothing', the simulated 24h grid, and the explanation of wall-clock rules and daypart reweighting. This helps the agent understand why a dry-run is needed and what the preview represents.

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, all dense with purpose-built information: return values, why it exists, how it differs, and payload reference. No filler 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?

Even without an output schema, the description clearly lists the return object and its fields. It explains what the preview is, references the sibling for payload consistency, and addresses tier-gating. For a validation tool with clear annotations, this is fully sufficient.

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 75%, so the baseline is 3. The description adds value by explaining the rules semantics ('rules are wall-clock, slots start on-or-after their time') and pointing to 'Same payload as set_schedule_rules' for the full shape, which aids parameter understanding. It does not, however, detail each parameter individually.

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 'DRY-RUN a ruleset' and specifies the exact return structure, making the tool's purpose unmistakable. It explicitly contrasts with set_schedule_rules ('Unlike set_schedule_rules...'), clearly distinguishing this validation tool from the mutation sibling.

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?

States 'Intended as the dry run for set_schedule_rules', giving an explicit when-to-use directive. It also notes the tier-gating difference ('not tier-gated and works on any tier') and references 'Same payload as set_schedule_rules', providing clear guidance on how to invoke it relative to another tool.

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