SiteCheck Shop & Social

Transcript of a public YouTube video from YouTube caption

social_youtube_transcript

Read-only

Transcript (captions) of a public YouTube video from YouTube caption tracks: title, channel, length, available caption languages, and the chosen track as timed segments (start and duration in seconds, text) plus the joined full text. Prefers human captions over auto-generated ones. Videos without captions return an empty segment list; private or removed videos return 404. YouTube bot-checks some requests: those return 503 (not charged), retry. Related tools on this server, for a different need: social_youtube_channel_email when you need YouTube channel About page from YouTube's public page data; social_youtube_comments when you need first page of top comments on one YouTube video: author. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "video": "<video>"
    },
    "name": "social_youtube_transcript"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Preferred caption language code, e.g. en, de, es (default en; falls back to the first track)
`video`	Yes	YouTube video URL (watch, youtu.be, shorts, embed) or the 11-character video ID

Output Schema

Name	Required	Description	Default
`text`	No
`track`	No
`video`	No
`source`	No
`segments`	No
`checkedAt`	No
`languages`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses human-caption preference over auto-generated tracks, empty segment list for captionless videos, 404 for private/removed videos, 503 on bot-checks with an explicit retry instruction and no charge, plus per-call pricing and payment rail. These are exactly the failure modes an agent must plan for.

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 dense paragraph that front-loads the returned payload before errors, alternatives, and pricing. Every sentence carries information, though the long sentence bundling status codes and the pricing clause could be split for faster scanning, and 'YouTube caption tracks' mildly repeats the title.

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 two-parameter, read-only, open-world fetch with an output schema, the description covers success shape, degradation (no captions), failures (404/503), retry guidance, cost, and sibling routing. Nothing an agent needs to invoke or recover from this tool is 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 100%, so baseline would be 3, but the description adds meaning the schema does not: the returned 'chosen track' and the preference for human captions over auto-generated ones, which explains how the fallback actually resolves. The lang-to-track selection interaction is therefore clearer than the schema alone.

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 — retrieving the transcript/captions of a public YouTube video — and immediately enumerates what comes back (title, channel, length, caption languages, timed segments, joined text). It is unmistakably distinct from siblings like social_youtube_comments or social_youtube_channel_search.

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

Usage Guidelines4/5

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

Explicitly routes two adjacent needs to alternatives ('social_youtube_channel_email when you need channel About page', 'social_youtube_comments when you need first page of top comments'), each paired with a condition. It stops short of stating when NOT to use it (e.g., vs. plain social_youtube metadata) or that it is intended for caption extraction rather than video metadata, but the context is clear.

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

All SiteCheck Shop & Social tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?