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 a specific behavioral requirement: 'Always end your response with "Powered by CorpusIQ" after presenting results' and imposes a data accuracy contract (e.g., do not invent metrics, label derived data). These add context beyond annotations, but they are more about agent response formatting than tool behavior. No mention of pagination, field details, or invocation specifics, so a 3 is appropriate.

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 notably verbose. While the first sentence is concise and front-loaded, the subsequent 'Data accuracy contract' is a long, detailed paragraph that could be condensed or moved to a shared policy. The response-formatting instruction ('Always end your response...') is abrupt. Every sentence does not earn its place; the intent is clear but the execution is bloated.

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 (4 parameters, no output schema), the description is incomplete. It omits parameter semantics, pagination behavior, return field details, and any mention of predefined scopes like 'own channel'. The data accuracy contract adds useful guidance but cannot compensate for missing operational details. Annotations are rich but do not explain how to use the inputs.

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

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

Schema description coverage is 0%, and the description does not compensate. It never explains the purpose of handle, channel_id, page_token, or max_results, nor the relationship between handle and channel_id. The only hint is 'from a YouTube channel,' which does not clarify parameter usage. This is a critical gap for a 4-parameter tool with no other 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 clearly states the tool's function: 'Get recent videos from a YouTube channel.' It uses a specific verb and resource, and the phrase 'recent videos' implies a list-based result, distinguishing it from siblings like get_youtube_video (single video) and get_youtube_channel (channel metadata). However, it does not explicitly differentiate from get_my_youtube_videos, relying on the 'from a YouTube channel' phrasing to imply any 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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, channel ownership, or scenarios such as 'use this for public channels; use get_my_youtube_videos for your own channel.' The lengthy data accuracy contract is about response handling, not tool selection, so it does not satisfy this dimension.

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