Building an AI Agent That Can Search and Summarize Podcasts (MCP Tutorial)

July 21, 2026

AI agents — Claude, or anything you build on an agent framework — are good at reasoning over content once they have it. The gap is getting it. If you want an agent that can find a podcast and summarize what was actually said, you hit a wall fast: many podcast APIs assume a human developer wiring endpoints together — handling API keys, paging results, and writing a parser for whatever transcript format each show happens to publish. Handing all of that to a model as ad-hoc tool wrappers is a lot of glue.

One config, five tools

PodKit ships an MCP (Model Context Protocol) server built for exactly this. Point your agent at it once and it gets five tools, each mapping to a real endpoint:

  • search_podcasts — find shows by keyword
  • get_podcast — a show plus a page of its episodes (each with an id)
  • get_episode — one episode’s metadata
  • get_episode_chapters — normalized chapter markers
  • get_episode_transcript — the transcript as clean, timestamped JSON

The model calls them directly — no wrapper code, and the same normalized JSON the REST API returns. Crucially, transcripts come back already parsed: whether a show published WebVTT, SRT, JSON, or plain text, your agent sees one consistent shape and never has to reason about file formats.

Connect it

In Claude Code:

claude mcp add --transport http podkit https://podkitapp.com/mcp \
  --header "x-api-key: YOUR_PODKIT_KEY"

Or in Claude Desktop (or any client via mcp-remote), add to claude_desktop_config.json:

{
  "mcpServers": {
    "podkit": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://podkitapp.com/mcp", "--header", "x-api-key:${PODKIT_KEY}"],
      "env": { "PODKIT_KEY": "YOUR_PODKIT_KEY" }
    }
  }
}

What an interaction looks like

Say you prompt the agent: “Find the latest episode of The Daily and summarize its key points.” With the tools available, it chains the calls itself:

  1. search_podcasts { "q": "The Daily" } → matches the show; the agent reads the id from the top result.
  2. get_podcast { "itunesId": "1200361736" } → episodes come back newest-first; the agent takes episodes[0].id.
  3. get_episode_transcript { "id": "8842" } → a normalized transcript: a flat text field plus timestamped, speaker-tagged segments.
  4. The agent summarizes from the transcript text — grounded in what was said, not guessed from the title.

That episode id is the important link: get_podcast hands back the id, and the episode/chapters/transcript tools consume it. The agent never has to know how PodKit stores anything — it just follows the ids from one tool to the next, the same chain a REST client would follow by hand.

Auth and quota are shared with the REST API

There’s no separate pricing or key for agent use. The MCP connection authenticates with the same x-api-key, and each tool call counts as one request against your normal monthly plan quota (protocol handshake and tool-discovery calls are free). Whether your traffic comes over REST or MCP, it’s metered the same way — so you can prototype an agent and move it to production without a billing surprise.

Try it

Point your agent at PodKit’s MCP server, or read up on the highest-value tool for agents — the Transcript API, which turns four transcript formats into one shape your model can reason over.

Connect via MCP →   Transcript API

← All posts