Skip to main content
Glama

Summarize a podcast episode

summarize_episode
Read-onlyIdempotent

A summary of one long interview or podcast episode Real Alpha cut, found by its YouTube or realalpha.app link, or by words naming it (the show and the guest, or its title): what it covers, the guests and what they do, a point for each part of the conversation with its time, its best minutes in the speaker's own words, the opening of its full analysis, and the page to cite. Use it when someone shares a YouTube link to an AI interview or podcast, or asks to summarize, recap or get the key points of an episode: you can't watch the video, and Real Alpha has listened to it. It covers the episodes Real Alpha cut from the shows it follows; for one it hasn't cut it says so, and how to ask for it.

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": {
      "episode": "<episode>"
    },
    "name": "summarize_episode"
  }
}

Input Schema

NameRequiredDescriptionDefault
showNoOnly episodes of this show: "No Priors"
episodeYesA YouTube or realalpha.app/v/ link, a video id, or words that name it: "Boris Cherny on Lenny's Podcast", "the latest Dwarkesh Podcast"

Output Schema

NameRequiredDescriptionDefault
cutNoWhether Real Alpha cut it: only cut episodes have a summary
dekNoThe episode in a sentence
tipNoWhat to try when nothing matched
urlNoThe episode's page on realalpha.app, which plays it: the link to cite
citeNo
dateNoWhen the episode came out, YYYY-MM-DD
showNo
foundYesWhether Real Alpha knows the episode
hostsNo
videoNoThe YouTube video id, for transcript_excerpt
guestsNo
pointsNoA point for each part of the conversation, in order
episodeNo
summaryNo
youtubeNo
analysisNoThe opening of Real Alpha's full analysis of the episode, and where the rest is
show_pageNo
backgroundNoWho the guests are, and the context
guests_areNoWhat the guests do, in the same order
transcriptNo
best_momentsNoThe episode's best minutes, best first
other_matchesNoOther episodes the words matched, for when this is the wrong one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent read with openWorldHint=false, so the bar is lower. The description still adds real behavior beyond them: a hard coverage boundary ('the episodes Real Alpha cut from the shows it follows') and a defined fallback when the episode is out of corpus. Listing the return fields is partly redundant given the output schema exists.

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

Conciseness3/5

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

The trigger and scope are front-loaded, but the opening sentence is a long run-on stacking six enumerated return fields, and that enumeration duplicates what the output schema already documents. It would be tighter with the field list trimmed or pushed into structured data.

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 tool with full schema coverage, annotations covering the safety profile, and an output schema, this description covers everything an agent needs: what it returns, when to reach for it, its corpus boundary, and what happens when the episode 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 is 3. The description modestly enriches it by clarifying that the query can be a link or 'words naming it (the show and the guest, or its title),' which signals tolerance for loose natural-language identification rather than requiring an exact id.

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?

Names a specific verb and resource ('A summary of one long interview or podcast episode') and pins down the scope: episodes Real Alpha has cut, identified by link, video id, or descriptive words. The enumeration of what the summary contains (coverage, guests, timestamped points, best minutes, analysis opening, citation page) makes the output unambiguous and separates it from a plain transcript or keyword search tool.

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 a concrete trigger: 'when someone shares a YouTube link to an AI interview or podcast, or asks to summarize, recap or get the key points of an episode,' with the rationale that the agent cannot watch video. It also states the miss case (episodes not cut are reported as such, with how to request them). It stops short of naming a sibling alternative or an explicit when-not-to-use, so it is clear context without full routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources