YouTube MCP Server

Youtube Get Video Stats

youtube_get_video_stats

Fetch view, like, and comment counts for one or up to 50 YouTube videos in a single call, returning successful results and failed IDs for partial batches.

Instructions

Get view, like and comment counts for up to 50 videos in one call.

Accepts one ID or a list. Uses videos:batchGetStats, which has its own 10,000-call/day bucket — this does not consume the shared pool that youtube_get_video draws on, so it is the cheap way to get numbers. Results are cached for ~3600 seconds (the server's CACHE_TTL_SECONDS; default 3600), or cached forever when that setting is 0 — there, 0 means never expires, not "zero seconds" — so re-reading the same videos costs no quota at all (cached: true only when every requested video's value came from the cache; false otherwise).

A batch is not atomic: IDs that do not exist or are not publicly visible come back as failed_video_ids, with the successful ones still returned. Surface both — this is partial success, not an error. Counts are as of the last call: view_count moves, like_count and comment_count too. dislike_count does not exist and is not returned by any YouTube endpoint — YouTube made dislikes private in December 2021, so there is no way to obtain them; do not attempt a workaround.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`video_ids`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	No
`cached`	No
`failed_video_ids`	No
`requested_video_count`	No
`succeeded_video_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses the separate quota bucket, cache TTL (~3600s and the 0-means-forever semantics), the non-atomic batch behavior with failed_video_ids, and the fact that dislike_count is unavailable and must not be worked around. These are exactly the operational traits an agent needs beyond structured fields.

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

Conciseness4/5

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

Front-loaded with the core purpose and the key quota insight, and every sentence carries new information. It is dense and slightly long with nested parentheticals about cache semantics, but little of it is filler.

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

Completeness5/5

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

An output schema exists, so the description needn't restate return values, and it goes further by explaining the partial-success shape (failed_video_ids alongside successful results) and the cached flag semantics. Nothing an agent needs to call this correctly and interpret the response appears to be missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does: it explains the parameter accepts either a single ID or a list and enforces an 'up to 50 videos' cap that the schema does not convey. It does not specify ID format (e.g., raw ID vs URL), leaving a minor gap.

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

Purpose5/5

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

States a specific verb and resource ('Get view, like and comment counts') plus the scope ('up to 50 videos in one call' and 'one ID or a list'). It explicitly contrasts itself with the sibling youtube_get_video, so an agent can distinguish it without opening either schema.

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

Usage Guidelines5/5

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

Names the alternative (youtube_get_video) and gives the exact condition that selects this tool: it uses its own 10,000-call/day bucket and 'does not consume the shared pool that youtube_get_video draws on, so it is the cheap way to get numbers.' Clear when-to-prefer guidance with the rationale.

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

Deploy Server