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

Goes well past the annotations (readOnlyHint=false, openWorldHint=false, destructiveHint=false): it defines the data_availability states (complete, observed_zero, no_rows, partial_collection, access_error), warns that no_rows/access_error are not zeros, explains truncated/partial_collection signaling, states row_limit defaults to 1000 and is not a quota sent to Google, specifies that only safe resumptions produce next_page_token, and discloses a per-call token cost plus that the call creates and stores a job. Note the internal tension: '읽기만 합니다' reads as read-only while the closing lines correctly say the call is not purely read-only, matching the annotation — that reconciliation keeps it from being a contradiction, but the earlier sentence is misleading on its own. A large block about anonymous recovery_receipts and file retention is generic boilerplate that does not clearly apply to this authenticated, channel-scoped call.

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 useful YouTube-specific content is front-loaded, but it is followed by a long, unstructured tail about xlsx artifacts, 7-day retention, 15-minute download_urls, xdata__job__result, anonymous recovery receipts, and idempotency-key policy, much of it in English inside an otherwise Korean description. Several of these paragraphs appear to be generic platform boilerplate that does not apply to this call, so the agent must sift relevant from irrelevant text to find the pagination rule.

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 no output schema, the description carries the return-value burden and does it well: it lists the returned fields, the data_availability vocabulary, and the truncated/DATA_AVAILABILITY partial_collection signal. Pagination and the artifact/download path are also covered. The remaining gap is relevancy rather than coverage — anonymous receipt handling and generic file-retention rules add volume without helping an agent call this authenticated listing tool correctly.

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

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

Schema description coverage is already 100%, so a 3 would be the floor, but the description adds real meaning the schema lacks: row_limit is the number of rows returned by this call rather than a limit pushed to Google, and page_token should be used only when next_page_token was populated, otherwise row_limit should be increased. The channel-ownership constraint on channel_id is reinforced in prose, though output_formats and request_idempotency_key are only covered by the schema and the trailing boilerplate.

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?

Opens with a specific verb+resource in the first sentence: it enumerates videos uploaded to the selected YouTube channel and names the exact fields returned (video_id, 제목, 공개 시각, 공개 범위). It also distinguishes itself from the write siblings by referring to the 영상 정보 수정 / 영상 삭제 tools by role, so an agent can tell it apart from google__youtube__video__update without opening the schema.

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?

Gives an explicit positive use case with a negative counterpart: when the outcome of an update/delete tool is unknown, do not re-issue the write — call this tool to verify. It also tells the agent how to choose between page_token continuation and raising row_limit. What it does not state is the more common trigger (simply wanting a channel's video inventory), and it never contrasts with google__youtube__playlist__list, which an agent could plausibly confuse it with.

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