Spotify MCP Server

Overview Schema Source Related Servers Discussions Admin

Control Playback

control_playback

Control Spotify playback: play, pause, skip, seek, adjust volume, toggle shuffle, or set repeat. Requires Premium and an active device.

Instructions

Control Spotify playback. Requires Premium and an active device.

Args:
    action: 'play', 'pause', 'next', 'previous', 'seek', 'volume', 'shuffle' or 'repeat'
    track_ids: Tracks to play (action='play'; ignored when context_uri is set)
    context_uri: Album/playlist/artist URI to play (action='play')
    position_ms: Position in milliseconds (required for action='seek')
    volume_percent: Volume 0-100 (required for action='volume')
    state: 'on'/'off' for shuffle; 'track'/'context'/'off' for repeat
    device_id: Target device (default: the currently active one)

Returns:
    Last observed PlaybackState, possibly unconfirmed.

Confirmation is best effort: at most five post-action reads with brief waits.
Stale state or a later read failure returns the last observation. Checks do not
verify every requested track, context or device transition.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`state`	No
`action`	Yes
`device_id`	No
`track_ids`	No
`context_uri`	No
`position_ms`	No
`volume_percent`	No

Output Schema

TableJSON Schema

Name	Required	Default
`track`	No
`device`	No
`repeat`	No	off
`volume`	No
`shuffle`	No
`is_playing`	Yes
`progress_ms`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.1Sep 17, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Given annotations already mark it as a mutating, non-idempotent operation, the description goes further by disclosing that confirmation is best effort with at most five post-action reads, that stale state may be returned, and that verification does not cover every requested transition. This goes well beyond the annotation's bare flags and compensates for the open world nature.

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?

The description is structured with a one-line summary, prerequisites, a labeled Args block, Returns note, and a caveats paragraph. It is longer than minimal, but the length is justified by the number of parameter dependencies and behavioral caveats; there is no redundant prose.

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 seven-parameter tool with zero schema descriptions, the description covers prerequisites, parameter semantics, and best-effort return behavior. It does not enumerate error conditions or invalid-action handling, but the output schema covers return types, so the description is complete enough for an agent to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so this description carries the full burden of explaining parameters. It defines each argument: action values, track_ids vs context_uri precedence, position_ms and volume_percent requirements, state options, and device_id default. This is exactly the level of semantic detail the schema lacks.

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?

The description states 'Control Spotify playback' and enumerates the exact actions (play, pause, seek, volume, shuffle, repeat), making the function's job unmistakable. It does not name sibling tools explicitly, but the action list clearly differentiates it from readers like get_playback_state and transfer_playback.

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 description implies usage by requiring a Premium subscription and an active device, and by tying specific parameters to specific actions. It does not explicitly compare this tool with siblings like get_playback_state or transfer_playback, nor state when not to use it. So usage guidance is implied rather than explicit.

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