Skip to main content
Glama

apple_podcasts_episodes

Get per-episode plays, unique and engaged listeners from Apple Podcasts Connect over a date range, ranked to show which episodes held attention. Requires explicit date range and row cap.

Instructions

Per-episode listening from Apple Podcasts Connect over a date range: plays, unique listeners, and engaged listeners for each episode, rolled up across the range and ranked. Answers 'which episodes held attention on Apple'. Apple aggregates from unique devices, so these are device counts, not headcounts, and an engaged listener is a device that played at least 20 minutes or 40% of an episode — a depth threshold, not a completion. Takes an explicit date range and a row cap; both are required to keep the response bounded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd of the range, YYYY-MM-DD (or YYYY-MM for Monthly). Defaults to 2 days ago, because Apple publishes reports on a lag.
limitNoMax episodes to return, ranked by sort_by. Default 10, cap 50.
startNoStart of the range, YYYY-MM-DD (or YYYY-MM for Monthly). Defaults to 7 days back for Daily, 7 weeks for Weekly, 6 months for Monthly — each sized to fit the default max_periods of 7.
periodNoReporter period. Daily and Weekly take YYYY-MM-DD dates; Monthly takes YYYY-MM. Weekly dates are Apple's week-ending Sundays.Daily
sort_byNoWhich metric ranks the episodes. Default plays.plays
worldwideNoUse the worldwide episode report instead of the per-storefront one. Per-storefront repeats every episode once per country, which is far more rows for the same totals.
max_periodsNoHow many periods to fetch, cap 31. Reporter has no range query, so each period is a separate call to Apple and a wide range will hit their throttle. Default 7. Ranges longer than this are truncated to the most recent periods.
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels: it discloses that Apple aggregates by unique devices (device counts not headcounts), explains the engaged listener threshold (20 minutes or 40%), and notes the bounded response requirement. This is rich behavioral context beyond the schema.

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?

The description is appropriately concise—four sentences, each earning its place: purpose, use case, metric semantics, and response-boundary constraint. It is front-loaded and contains no fluff or repetition.

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?

The rich schema combined with the description covers purpose, metrics semantics, and constraints well. There is no output schema, but the description implies output structure (ranked episodes). Minor ambiguity about 'required' params (schema shows defaults) leaves a small gap, preventing a 5.

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 description coverage is 100%, with all 7 parameters well-documented. The description adds rationale for date range and limit (bounded response) but does not substantially enhance per-parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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 tool provides per-episode listening metrics (plays, unique listeners, engaged listeners) over a date range, rolled up and ranked. It uses specific verb and resource (Apple Podcasts Connect episodes) and is well differentiated from siblings like summary and followers by focusing on episode-level attention.

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 context on when to use this tool ('Answers which episodes held attention on Apple') and implies differentiation from siblings (summary, followers). However, it does not explicitly name alternatives or state exclusions, so it stops short of full guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/conorbronsdon/apple-podcasts-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server