youtube-growth

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining it scores from the 'public catalogue' and returns a prioritized fix, which goes beyond the annotations. No contradiction with annotations.

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

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

The description is two sentences, front-loaded with the core purpose and outcome, followed by usage guidance. Every word earns its place with no filler or repetition.

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

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

Given the tool's simplicity (single parameter, read-only, idempotent) and lack of an output schema, the description adequately covers purpose, usage, and output format ('score out of 100' and 'one thing to fix first'). Minor gaps like error behavior or definition of 'public catalogue' are not critical for 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?

The input schema has 100% coverage, with a detailed description of the 'channel' parameter (accepting @handle, URL, channel id, or name). The description adds no further parameter-specific detail, so the baseline score of 3 applies since the schema already does the heavy lifting.

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

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

The description uses a specific verb 'Scores' with the resource 'YouTube channel' and clearly defines the output: 'out of 100' and 'returns the one thing to fix first'. This distinguishes it from sibling tools like check_monetization_progress or get_channel_patterns, which focus on different aspects.

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: 'Use this when asked how a channel is doing, or to compare a channel against its own history rather than against other channels.' This includes a clear exclusion ('rather than against other channels'), though it does not name alternative tools, leaving some ambiguity about when to pick a sibling.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the Shorts-views path measured over the last 90 days and the exact tier thresholds, which is useful beyond the annotations. 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?

The description is two sentences: the first states the function with key details, the second gives a direct usage directive. Every sentence earns its place with no redundancy or filler.

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

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

Given the tool's simplicity (one parameter, read-only, robust annotations), the description adequately explains what it reports (progress toward tiers) and the time window. It doesn't spell out the return format, but since there's no output schema, the description covers the essential return content (distance and thresholds) well enough.

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 100% coverage for the single 'channel' parameter, including a clear description of accepted formats. The tool description does not add additional parameter-level semantics beyond what the schema provides, so the 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 with a specific verb ('Reports how far a channel is from') and a resource (YouTube monetization), specifying both tier thresholds (500 subscribers for fan funding, 1,000 for ad revenue). This is sufficiently distinct from sibling tools like audit_youtube_channel, which have broader or different scopes.

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 'Use this when asked whether a channel is close to monetization or what it still needs,' providing clear context for when to invoke this tool. It does not mention alternatives or exclusion criteria, so it stops short of a 5.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context by explaining the output is measured as a lift against the channel's own median and includes the number of uploads, making the tool's analytical behavior transparent.

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

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

The description is two sentences, front-loaded with what is returned, followed by when to use it. Every part adds value with no redundancy or filler.

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

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

With only one fully described parameter, strong safety annotations, and no output schema, the description adequately explains the tool's scope, benchmark method, and intended use. It doesn't detail output formatting, but the low complexity makes that omission acceptable.

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, is fully described in the schema with accepted forms (handle, URL, ID, or name), giving 100% schema coverage. The description contributes no additional parameter syntax or nuance, so a baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: it returns title length, duration, posting day, and format as performance lifts relative to a channel's own median, plus upload counts. This is specific and distinguishes it from generic YouTube advice and sibling tools like audit_youtube_channel or get_next_video_brief.

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

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

The description explicitly says to use it 'instead of generic YouTube advice' and 'when the question is why some of a channel's videos outperform others.' This gives a clear use case and an implicit exclusion, though it does not name sibling tools as 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, non-destructive, and idempotent. The description adds meaningful behavioral context: the brief is derived from channel performance ('derived from what already outperformed'). It also reveals what the brief includes, giving the agent expectations 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?

Two sentences, front-loaded with the tool's purpose and concrete output fields. The second sentence gives usage guidance without padding. Every word earns its place.

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

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

The tool is simple (one parameter, no output schema). The description covers what the tool returns and when to use it. Given the low complexity and complete schema, no further information is 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?

Schema description coverage is 100% for the single 'channel' parameter, including accepted formats (@handle, URL, ID, name). The description does not add parameter-specific details, but the schema already handles this fully, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Returns a brief') with a clear resource (the channel's next upload) and enumerates the exact content (format, length, title shape, posting day). This distinguishes it from sibling tools like get_channel_patterns and suggest_ab_test by its focus on a concrete actionable brief rather than analysis or suggestions.

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 states when to use: 'Use this when asked what someone should make or publish next.' This provides clear contextual guidance. It does not name alternatives or exclusions, but the usage instruction is sufficient for the scope of this tool.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral constraints: variants change exactly ONE element and are grounded in patterns measured on the channel. It also clarifies that the tool focuses on what to test, not whether to test, which is useful 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 two sentences, front-loaded with the primary action and constraints, followed by a clear usage guideline. Every sentence earns its place with no filler or redundant information.

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

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

Given the tool's moderate complexity, strong annotations, and complete schema, the description covers the essential context: what it does, when to use it, and key constraints. It does not describe the output format or number of variants, but the purpose implies a list of title variants. With no output schema, this slight gap is acceptable because the behavior is well understood from the description.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add extra parameter-level meaning beyond what the schema already provides (e.g., channel can be a handle, URL, ID, or name; title is optional). The mention of 'patterns measured on that channel' implicitly relates to the channel parameter but adds no syntactic or semantic detail not already in the schema.

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

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

The description clearly states the tool's function: it suggests title variants for YouTube's Test & Compare, with each variant changing one element and grounded in channel patterns. This is specific and goes beyond a generic verb. It distinguishes from siblings by contrasting 'what to test' with 'whether to test,' though it does not name an alternative tool explicitly.

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

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

The description provides explicit usage context: 'Use this when a creator has a video ready and wants to know what to test rather than whether to test.' This tells the agent when to invoke the tool, though it does not name specific alternatives or exclusions beyond the conceptual distinction.

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