Skip to main content
Glama

youtube_shorts

Fetch Shorts for a channel (~50 per page). Priced per page; defaults to 1 page.. Platform=youtube resource=shorts. Costs 6 credit(s). Requires Authorization: Bearer <api_key>. Credits unit: page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoPages to fetch. Defaults to 1.
browse_idYesChannel id (UC…). From User Info or a channel URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / browse_id / description
      Previous value: -"Channel id (UC…). From Resolve."New value: +"Channel id (UC…). From User Info or a channel URL."
  2. First observed

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses cost (6 credits), the pricing unit (page), the auth requirement (Bearer api_key), and the ~50-items-per-page rate. It does not state read-only semantics explicitly, but 'Fetch' implies it and the pricing/rate details are the operationally important facts.

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

Conciseness3/5

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

Front-loaded and short, but contains redundancy: 'defaults to 1 page' repeats the schema, while 'Priced per page' and 'Credits unit: page' say the same thing twice, and a stray double period ('page..') signals careless formatting.

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?

No output schema or annotations exist, yet the description covers the key unknowns: cost, pricing unit, auth, and page size. An agent has enough to call it correctly, with only return-value shape left unspecified.

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 the schema already documents both browse_id and depth. The description adds the ~50-per-page rate that helps interpret depth, but otherwise restates the 1-page default already in the schema.

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?

States a specific verb ('Fetch') and resource ('Shorts for a channel'), and the resource name inherently distinguishes it from youtube_videos/youtube_video in the sibling list. It does not explicitly name the alternative video tool, so it stops short of a 5.

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

Usage Guidelines2/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 versus youtube_videos or youtube_search; the only conditional content is the depth default. An agent must infer that 'Shorts' is a distinct content type from the name alone.

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.

Resources