Skip to main content
Glama
Sign In
mcp-youtube

mcp-youtube

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

YouTube: Request

youtube_request
Read-only

Call any YouTube Data API v3 GET endpoint that lacks a dedicated tool, such as captions, commentThreads, or search, and return the raw response.

Instructions

Escape hatch: call any YouTube Data API v3 endpoint (https://developers.google.com/youtube/v3/docs) that has no dedicated tool, e.g. GET /captions, GET /commentThreads, GET /search. The path is relative to /youtube/v3; parameters go in query. Returns the raw response, unshaped — prefer the dedicated tools. Media uploads (captions, banners) are not possible through it. Watch the cost: GET /search costs 100 units and has its own daily bucket. Writes are DISABLED: only GET is permitted. Set YOUTUBE_ALLOW_WRITES=1 to allow mutations.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "youtube_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoJSON body for POST/PUT.
pathYesPath under /youtube/v3, e.g. "/captions" or "/commentThreads".
queryNoQuery parameters, e.g. {"part": "snippet", "videoId": "dQw4w9WgXcQ"}.
methodNoHTTP method.GET

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the supplied annotations, it discloses the raw/unshaped return, quota cost semantics (GET /search = 100 units with its own daily bucket), and the disabled-write posture plus the YOUTUBE_ALLOW_WRITES override. Minor tension: the env var override means the readOnlyHint=true annotation reflects only the default configuration, but the description itself states the default clearly, so this is a nuance rather than a contradiction.

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?

Four tight sentences, front-loaded with the escape-hatch framing before the examples and caveats. Slight redundancy in re-explaining the /youtube/v3 path prefix that the schema already covers.

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?

For a raw pass-through API tool with no output schema, the description covers return shape, cost, capability limits, method restriction, and the enabling env var — everything needed to call it safely without surprises.

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 path, query, and method are already documented with examples. The description's 'path is relative to /youtube/v3; parameters go in query' largely restates the schema, and it says nothing about the body parameter, which the schema advertises for POST/PUT even though only GET is permitted — a gap the description could have closed.

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?

The description states a specific verb and resource ('call any YouTube Data API v3 endpoint') and frames it explicitly as an 'escape hatch' for endpoints with no dedicated tool, listing concrete examples (GET /captions, /commentThreads, /search). This makes it immediately distinguishable from the sibling list/get tools that cover the common endpoints.

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?

It gives an explicit selection rule ('that has no dedicated tool... prefer the dedicated tools'), explicit exclusions (media uploads are not possible), and explicit constraints on method (only GET). An agent knows both when to reach for this and when to fall back to siblings.

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