Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apple_podcasts_show_episodes

Get an Apple Podcasts show and its episodes by ID, with controls for limit, country, and language.

Instructions

Retrieve Apple Podcasts show episodes. Returns one Apple Podcasts show by its Apple show id, together with a list of its episodes. limit sets how many episodes to return; country and lang choose the storefront and language. Episodes have title, description, duration_millis, release_date, episode_url and episode_guid.

Input Schema

NameRequiredDescriptionDefault
idYesApple Podcasts show ID
langNoResult language tag
limitNoNumber of episodes to return
countryNoTwo-letter storefront country code

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0
  2. Removedv1.6.0
  3. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses the return shape (show + episode fields like duration_millis and episode_guid), but says nothing about pagination for limit, auth requirements, or how missing/empty episode lists are handled.

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

Conciseness4/5

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

Three front-loaded sentences with no filler; the opener is slightly redundant with the more precise second sentence, but each remaining sentence adds param or return detail.

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?

Without an output schema the description steps in to enumerate returned episode fields, and it covers all four parameters, which is sufficient for a read-only lookup. Only the absence of pagination/limit-boundary behavior keeps it from being fully complete.

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, but the description adds functional meaning: limit is the episode count, country selects the storefront, and lang selects the result language. That goes beyond the schema's terse labels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (retrieve Apple Podcasts show episodes) and clarifies the payload is one show plus its episode list. It implicitly distinguishes itself from apple_podcasts_show by promising episodes, but never names that sibling so the boundary must be inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no alternatives cited. With siblings like apple_podcasts_show and apple_podcasts_episodes_search present, the agent gets no help deciding between fetching a show with episodes versus searching episodes directly.

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