Apple Podcasts MCP

One episode from your library, in full

get_library_episode

Read-onlyIdempotent

Fetch a full podcast episode by its local ID, returning complete show notes and the entire cached transcript excerpt for analysis.

Instructions

One episode by its local id, with complete show notes and the whole cached transcript excerpt rather than a trimmed one. Local ids come from search_library and the other library tools.

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": {
      "id": "<id>"
    },
    "name": "get_library_episode"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The local episode id, as returned by the other library tools.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Sep 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: episodes are locally identified, return complete show notes, and return the whole cached transcript excerpt rather than a trimmed version. This gives the agent meaningful expectations about scope and data source.

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?

Two concise sentences fully carry the purpose, the key behavioral distinction, and the source of the required id. There is no redundant or filler content, and the important 'in full' distinction 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?

For a simple one-parameter read-only getter with rich annotations and no output schema, the description is complete enough. It tells the agent what the tool returns, how to obtain the id, and how this tool differs from trimmed variants, so the agent can correctly select and invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: the id parameter is already described as the local episode id returned by other library tools. The description reinforces this by naming search_library, but does not add materially new meaning beyond 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?

The description clearly states the resource (one library episode), the lookup method (local id), and the distinguishing full-content behavior (complete show notes and whole cached transcript excerpt rather than a trimmed one). This differentiates it from other library and episode tools without needing to inspect schemas.

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?

The description gives clear context on when to use this tool: when you already have a local episode id from search_library or other library tools and want the full episode content. It does not explicitly name alternative tools for trimming or for non-library episodes, so it stops short of full when/when-not guidance.

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