Skip to main content
Glama
Sign In

YouTube Transcript AI

by ai.youtube-transcript
OverviewDiscussionsAdmin

search_spoken_words

Search what people actually say inside YouTube videos. Full-text search over about 100 million spoken sentences from about 425,000 English-language videos (the ones users looked up on youtube-transcript.ai), with typically 1 to 8 million new sentences added every day. Returns matching sentences, each with the video, channel and a link that opens the video at that moment. Use it to find evidence and quotes, to see how people talk about a topic, product or phrase, or to find which videos mention something. Captions are auto-generated and often mis-hear names (for example "Claude Code" is often written "cloud code"), so pass likely mis-hearings in also_match. The library is a sample of YouTube, not all of it. Dates are the day we captured the captions, not the day the video was published.

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": {
      "query": "<query>"
    },
    "name": "search_spoken_words"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many sentences to return. Default 10.
queryYesA word or short phrase (up to 8 words), e.g. "claude code" or "break the ice". Plain words only, no search operators.
sinceNoOnly captions captured on or after this date, YYYY-MM-DD.
untilNoOnly captions captured on or before this date, YYYY-MM-DD.
channelNoOnly this channel: a channel ID (UC...) or part of the channel name.
also_matchNoOther spellings or mis-hearings to count as the same thing, e.g. ["cloud code"]. Up to 5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses corpus size and daily growth, that the library is a sample of YouTube rather than all of it, that captions are auto-generated and mis-hear names, and that dates are capture dates rather than publish dates. It omits auth/rate-limit and pagination behavior, keeping it below a 5.

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

Conciseness5/5

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

Five sentences, each earning its place: purpose first, then corpus scope, then use cases, then the mis-hearing workaround, then the two important caveats (sampling and dates). Nothing is repeated and the most decision-relevant information is front-loaded.

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?

A read-only search tool with a fully documented six-parameter schema and no output schema; the description covers what is returned (matching sentences with video, channel, and a timestamped link) and flags the data-quality caveats an agent needs before trusting results. Nothing essential for correct invocation 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 the baseline is 3; the description adds real value beyond it by explaining that also_match should carry likely mis-hearings (with the "cloud code" example) and by clarifying that since/until filter on caption capture date, not video publish date. Query syntax limits are left entirely to the schema.

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 — full-text search over ~100M spoken sentences from ~425k YouTube videos — and adds scope (English-language, cross-video) that separates it from transcript-per-video and metadata tools like find_in_transcript or search_youtube_videos. An agent can tell what this returns without opening the schema.

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?

Gives explicit when-to-use cases: find evidence and quotes, see how people talk about a topic/product/phrase, or find which videos mention something. It does not name sibling alternatives or state when not to use it (e.g., searching inside one known video), so it falls short of a 5.

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

All YouTube Transcript AI toolsInspect
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