Skip to main content
Glama
Galbaz1

video-research-mcp

by Galbaz1

Video Playlist

video_playlist
Read-onlyIdempotent

Extract video IDs and titles from a YouTube playlist to pass to video_analyze for batch analysis. Set the playlist URL and maximum items to return.

Instructions

Get video IDs and titles from a YouTube playlist.

Results can be passed to video_analyze for batch analysis. Costs 1 YouTube API unit per page (max 50 items/page).

Input Schema

NameRequiredDescriptionDefault
urlYesYouTube playlist URL (must contain 'list=' parameter)
max_itemsNoMaximum videos to return

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: cost of 1 YouTube API unit per page and a 50-item page cap, which helps the agent reason about quota and batching. Pagination semantics beyond 'per page' are not spelled out.

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

Conciseness5/5

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

Three short, front-loaded sentences with zero filler: purpose first, downstream use second, cost third. Every sentence carries distinct information and nothing is wasted.

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

Completeness4/5

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies cost context, and both parameters are documented. The only mild gap is pagination behavior and how to iterate past the first page, but overall it is complete for calling the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so both url and max_items are already fully documented in the schema. The description's mention of 'max 50 items/page' loosely reinforces the max_items ceiling but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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

Purpose4/5

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

The description states a specific verb and resource: 'Get video IDs and titles from a YouTube playlist.' This is precise and tells the agent exactly what data comes back. It does not, however, explicitly differentiate itself from similar siblings like video_metadata or youtube_channel_inspect, which also return video-level data.

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

Usage Guidelines3/5

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

Usage is only implied through 'Results can be passed to video_analyze for batch analysis,' which hints at the downstream workflow. There is no explicit when-to-use-vs-alternatives guidance, no prerequisites, and no statement of when this tool is the wrong choice.

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

Deploy Server

Other Tools