Skip to main content
Glama
Sign In
Spotify MCP Server

Spotify MCP Server

by jamiew
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check Saved Episodes

check_saved_episodes
Read-onlyIdempotent

Checks which podcast episodes are already saved in Spotify by episode IDs or URIs, returning each episode’s saved status so you can avoid duplicate saves.

Instructions

Check which podcast episodes are already saved, in upstream chunks of 40.

Args:
    episode_ids: Episode IDs or URIs (up to 50)
Returns:
    MembershipStatus.results maps each Spotify episode id to true if saved

Input Schema

NameRequiredDescriptionDefault
episode_idsYes

Output Schema

NameRequiredDescriptionDefault
checkedYes
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish read-only and idempotent behavior, so the description's real contribution is the upstream chunking of 40 and the up-to-50 input ceiling — genuine behavioral detail an agent can't get elsewhere. It does not state error or partial-failure behavior, keeping it below 5.

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?

Front-loaded purpose statement followed by compact Args/Returns blocks; every sentence carries information. The Returns line is somewhat redundant given an output schema exists.

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?

For a single-parameter read tool with annotations and an output schema, the description supplies the purpose, the input types, the batch limit, and the chunking model. Remaining gaps (result ordering, behavior on invalid IDs) are minor.

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 0%, so the description carries the burden. It does add two important facts: the parameter accepts episode IDs or URIs, and it is capped at 50 items. However, it says nothing about the array item format beyond 'URIs' or what happens when the list exceeds a chunk.

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: check which podcast episodes are already saved. An agent can distinguish it from get_saved_episodes and save_episodes, though it never names those siblings explicitly, so it stops short of a 5.

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

Usage Guidelines3/5

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

The 'already saved' framing implies the use case (membership testing before save/remove), but there is no explicit when-to-use or when-not guidance, and no routing to the related get_saved_episodes / save_episodes / remove_saved_episodes tools.

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