list_playlist_itemsRetrieve videos from a YouTube playlist in order by playlist ID or exact title, with optional channel selection, to inspect or process playlist contents.
Videos in a playlist, in order.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Which connected channel: channel ID (UC...), @handle or name. Omit to use the default channel. | |
| playlist | Yes | Playlist id or exact title. | |
| page_token | No | ||
| max_results | No |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that results are ordered, while omitting pagination behavior despite page_token and max_results parameters, and omitting any indication of default or capped page size.
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 technically short, but it is under-specified rather than concise. A single fragment with no verb or usage context does not front-load actionable information for an agent.
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 four-parameter listing tool with no output schema, 50% schema coverage, and no pagination details in the description, this is not complete enough for reliable invocation. An agent cannot tell how paging works, what the result shape is, or why to choose this over sibling listing 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?
Schema description coverage is 50%, with channel and playlist documented but page_token and max_results undocumented. The description does not compensate by explaining pagination, the default of 50, or the maximum of 50, so it adds no meaning beyond the partially documented 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 is a noun phrase, 'Videos in a playlist, in order,' that essentially restates the tool title 'List videos in a playlist' without a specific verb. It implies the resource and ordering but does not clearly distinguish the operation from siblings like list_playlists or get_video beyond the object named.
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?
There is no guidance on when to use this tool versus list_playlists, get_video, or move_in_playlist, nor any note about required preconditions such as a connected channel. The only implied usage comes from the name and title, not the description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.