Skip to main content
Glama
Sign In
YouTube MCP

YouTube MCP

by pratikgh0se
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

youtube_preflight_caption_upload

Destructive

Validate and preview a caption upload for an owned video before committing, ensuring correct file, language, and format.

Instructions

Validate and preview a caption upload for an owned video.

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": {
      "videoId": "<videoId>",
      "filePath": "<filePath>",
      "mimeType": "<mimeType>",
      "language": "<language>",
      "name": "<name>"
    },
    "name": "youtube_preflight_caption_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesCaption track name shown to viewers, up to 150 characters.
isDraftNoWhether the caption track is a draft that is not shown to viewers.
videoIdYesID of an owned video the caption belongs to.
filePathYesAbsolute path to the local caption file.
languageYesCaption language code, e.g. en.
mimeTypeYesCaption file MIME type: application/octet-stream, application/ttml+xml, text/plain or text/vtt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.1
    • addedInput schema / properties / filePath / description
      Added value: +"Absolute path to the local caption file."
    • addedInput schema / properties / isDraft / description
      Added value: +"Whether the caption track is a draft that is not shown to viewers."
    • addedInput schema / properties / language / description
      Added value: +"Caption language code, e.g. en."
    • addedInput schema / properties / mimeType / description
      Added value: +"Caption file MIME type: application/octet-stream, application/ttml+xml, text/plain or text/vtt."
    • addedInput schema / properties / name / description
      Added value: +"Caption track name shown to viewers, up to 150 characters."
    • addedInput schema / properties / videoId / description
      Added value: +"ID of an owned video the caption belongs to."
  2. First observedv0.1.0

TDQS

C2.7/5.0
Behavior1/5

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

The description frames the operation as pure validation/preview, yet annotations declare destructiveHint=true, and the description does no work to reconcile that: it never states whether anything is written, staged, or left unchanged. It also omits what a "preview" yields (a validation report? errors?), which is the single most important behavioral fact for a preflight tool.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient but so short that its brevity tips into under-specification rather than crispness.

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

Completeness2/5

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

For a 6-parameter, 5-required preflight tool with no output schema and a destructive annotation, the description should at minimum explain the non-destructive guarantee and what the preview returns. Neither is present, and the relationship to youtube_upload_caption / youtube_preflight_caption_update is left for the agent to guess.

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% and all six properties carry their own descriptions (enum values for mimeType, constraints on language and name), so the schema already does the parameter work. The tool description adds no extra meaning about filePath locality, videoId ownership, or what isDraft changes in a preview, so the baseline 3 applies.

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?

Uses a specific compound verb ("validate and preview") against a specific resource ("a caption upload for an owned video"), which is far more informative than a restatement of the tool name. It does not, however, distinguish itself from the obvious sibling youtube_upload_caption or explain the preflight/apply relationship that the name implies.

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 explicit when-to-use guidance: nothing says this is the dry-run to call before youtube_upload_caption, or that the real upload is a separate tool. The only hints are the word "preview" and the phrase "owned video," which at best weakly imply a prerequisite check rather than stating one.

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