Video Streaming Data
get_v1_video_streaming_data(Some videos may be protected.) Group: Video. Billing per call: 1 Credits.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No |
youtube
by com.jojapi
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
D1.5/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states '(Some videos may be protected.)' – a vague caution that doesn't explain behavior such as failure modes, pagination, or authentication. It carries the full burden but gives almost no useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It wastes the little space on billing info and a vague protection warning, while omitting essential details about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with 0% schema coverage, no output schema, and no annotations, the description must fully explain what it does and what it returns. It fails completely, leaving the agent to guess the tool's purpose and output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter 'id' has a title 'Video ID' and an example but no description. The description adds no parameter meaning. The example provides some clue, but the tool description doesn't explain how the ID is used or any constraints, so it barely compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Video Streaming Data' but doesn't specify what operation it performs (fetch? list? analyze?) or what the data contains. It vaguely implies retrieving streaming data for a video but lacks a specific verb+resource combination. Siblings like get_v1_video_details suggest distinct functions, but this description doesn't differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 siblings. The description only mentions 'Group: Video' and billing credits, with no context about scenarios where this tool is appropriate or alternatives like search or video details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
D1.8/5.0
Disambiguation3/5
Several tools have overlapping purposes, notably get_v1_video_details and get_v2_video_details likely serve the same function, and post_channel_videos vs get_v1_channel_videos could confuse agents. Other names like get_v1_channel_channels are vague and lack clear boundaries.
Naming Consistency2/5
Naming mixes version prefixes (v1, v2) and verb variations (get, post). Many tools follow a pattern of get_v1_[category]_[resource], but exceptions like get_v1_auto_complete, get_v1_home, and get_v1_search break the consistency, creating a non-uniform convention.
Tool Count3/5
20 tools is on the higher end but still plausible for a YouTube API covering multiple resource types. However, duplicate tools (v1/v2) and overlapping features inflate the count and suggest unnecessary overhead.
Completeness3/5
The tool set covers a broad range of read operations—channels, videos, playlists, community posts, search, and trending—but lacks update/delete capabilities and only has one POST action. Duplicate endpoints also indicate redundancy rather than true expansion of coverage.