Skip to main content
Glama
Sign In
Uoink

Uoink

by ryanbiddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get transcript

get_transcript
Read-onlyIdempotent

Retrieve a YouTube video’s transcript with source provenance, falling back to local Whisper when captions are missing or blocked.

Instructions

Get the transcript of one YouTube video, with honest provenance. Use when you need what a video says; use search_clips to find passages across saved items or uoink_video to save a video with screenshots. Order: the saved library copy (no network), then captions fetched on this computer's own connection, then local Whisper on the audio when YouTube refuses captions (429, bot check) or has none. Returns source (library, captions, auto_captions or whisper), language, a plain why on any fallback, and the text; long transcripts page with next_cursor. Nothing is added to the library.

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": {
      "url": "<url>"
    },
    "name": "get_transcript"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesYouTube video URL (watch, youtu.be, Shorts, embed) or 11-character video ID.
langNoPreferred language code such as en, de or pt-BR. Default: English when YouTube has it, else the spoken language. Falls back to the available language and says so in why.
strip_adsNoAccepted for compatibility with other transcript servers and ignored: Uoink returns every word.
next_cursorNoSegment index from the previous response's next_cursor, to read the next page of a long transcript.
include_timestampsNoWhen true, each line starts with [m:ss] and segments carries start/end seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent and non-destructive, so the description correctly spends its words elsewhere: the three-tier fetch chain, which tier touches the network and which does not, the exact failure triggers (429, bot check, no captions) that cause local Whisper, and the explicit guarantee that 'Nothing is added to the library.' What it omits is cost/latency expectations — Whisper on audio is presumably slow, and that is not signalled.

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 with a distinct job: purpose, alternatives, fetch order, return shape, side-effect guarantee. Front-loaded with the verb and resource, and the densest sentence (the fallback chain) is ordered identically to how the tool actually resolves, so it reads as a sequence rather than a list.

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?

With no output schema, the description must describe returns, and it does: source, language, why, text, and next_cursor paging. For a multi-source tool with an external network dependency this is nearly complete; the missing piece is a hint about how large slow paths (Whisper transcription) behave, which matters for an agent deciding whether to call it inside a short loop.

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 schema carries the parameter burden and a baseline of 3 applies. The description still adds genuine meaning by tying next_cursor to paging of long transcripts, enumerating the possible source values returned, and explaining that a 'why' string accompanies any fallback — context an agent needs to interpret the response rather than the request.

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 — 'Get the transcript of one YouTube video' — and immediately bounds scope to a single video, which separates it from corpus-wide tools like search_clips and get_uoink_corpus. 'With honest provenance' further signals that source reporting is part of the contract, not an afterthought.

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?

Explicitly names when to use it ('when you need what a video says') and routes two alternatives by condition: search_clips for finding passages across saved items, uoink_video for saving a video with screenshots. It also supplies a resolution order (library, then captions, then Whisper), so the agent knows what happens without deciding the fallback itself.

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