What can you do with this server?

This server acts as an MCP interface to the Spotify Web API, enabling you to search, browse, and manage Spotify content via an AI assistant. * Authentication & Status — Sign in via OAuth (browser-based PKCE flow) and check your current login/configuration status. * User Profile — Retrieve your Spotify profile info (ID, display name, country, etc.). * Search — Search the Spotify catalog for tracks, albums, artists, or playlists using text queries or field filters (e.g. artist:radiohead, year:2020 genre:jazz). * Track Details — Fetch detailed information about a specific song by ID, URI, or URL. * Audio Features — Retrieve tempo/BPM, key, energy, danceability, and other metrics for a track (via ReccoBeats, since Spotify deprecated their own endpoint). * Playlist Management * List playlists you own or follow (paginated). * Get a specific playlist's metadata and tracks. * Create a new playlist with optional public/private, collaborative, description, and initial track settings. * Add one or more tracks to an existing playlist at a specific position or at the end. * Now Playing — See the track currently playing on your Spotify account.

Which integrations are available for this server?

Provides tools for searching Spotify, viewing song and playlist details, listing playlists, creating playlists, and managing playback.

How do I use Spotify MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Spotify MCP search for 'Bohemian Rhapsody'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Spotify MCP

by abenke

Overview Schema Related Servers Score Discussions

Python

Local

Spotify MCP

A local Model Context Protocol server for the Spotify Web API. Runs on your machine and lets an MCP client — Claude Code, the Coworker desktop app, or anything else that speaks MCP — search Spotify, view song and playlist details, list your playlists, and create new ones on your behalf.

Features

Tool	What it does
`authenticate`	Sign in to Spotify via OAuth (opens a browser). Run once.
`auth_status`	Check whether the server is authenticated and how it's configured.
`get_current_user`	Your Spotify profile (id, display name, country, …).
`search`	Search the catalog for tracks, albums, artists, or playlists.
`get_track`	Detailed info for a single song.
`get_audio_features`	Tempo/BPM, key, energy, danceability, etc. for songs (see note below).
`find_choruses`	Detect a song's choruses & repeated sections, with the length in seconds of each occurrence (see note below).
`list_my_playlists`	List the playlists you own or follow (paginated).
`get_playlist`	A playlist's details and its tracks.
`create_playlist`	Create a new playlist (optionally seeded with tracks).
`add_tracks_to_playlist`	Add songs to an existing playlist.
`get_currently_playing`	The track currently playing on your account, if any.

Related MCP server: Spotify Streamable MCP Server

How it works

Authentication uses the Authorization Code with PKCE flow — Spotify's recommended flow for locally-run apps, because it needs only a Client ID and no client secret. On first use the server opens your browser, you approve access, and the resulting tokens are cached at ~/.spotify-mcp/token.json and refreshed automatically. You typically authenticate just once per machine.

Audio features (tempo/BPM, key, energy, danceability)

Spotify deprecated its own audio-features and audio-analysis endpoints on 2024-11-27. Apps created after that date get 403 Forbidden, and there is no official replacement.

So get_audio_features instead uses ReccoBeats — a free third-party service that mirrors the same metrics and accepts Spotify track IDs. Two things to be aware of:

Track IDs you look up are sent to ReccoBeats (not Spotify).
The returned values are ReccoBeats' estimates, not Spotify's original numbers.

No API key is required. You can point the tool at a different base URL with the RECCOBEATS_BASE_URL environment variable.

Chorus detection (`find_choruses`)

Built for planning workouts, choreography, or class progressions around a song's structure: find_choruses reports every time the chorus (and any other repeated section, like a post-chorus hook) occurs, how long each occurrence runs in seconds — a chorus sung three times for 14 seconds each comes back as [14, 14, 14] — the gaps between occurrences, and a start-to-finish timeline of the song.

Since Spotify serves no raw audio and deprecated its audio-analysis endpoint (the one that exposed section timings), the analysis works from time-synced lyrics instead: a chorus is a block of lyric lines that repeats (near-)verbatim at several timestamps, and the line timestamps yield each occurrence's start, end, and duration. Lyrics come from LRCLIB, a free community lyrics database that needs no API key.

Things to be aware of:

You can identify the song by Spotify track ID or by artist + title — the latter needs no Spotify authentication at all.
The artist/title you look up is sent to LRCLIB (not Spotify). Point the tool at a different base URL with the LRCLIB_BASE_URL environment variable.
Instrumental tracks, and tracks LRCLIB doesn't have synced lyrics for, can't be analyzed. If only un-synced lyrics exist, sections are counted but not timed.
Durations run from the first line of a section to the first line of the next one, so a chorus's trailing instrumental bars count toward the chorus.
If a hook always follows the chorus, the lyrics give no evidence they are separate sections, and they'll be reported as one combined block.

Prerequisites

Python 3.10+
A free Spotify account
A Spotify app (for the Client ID):
1. Go to the Spotify Developer Dashboard and Create app.
2. Under Redirect URIs, add exactly:
  http://127.0.0.1:8888/callback
  Spotify requires loopback redirect URIs to use 127.0.0.1 (not localhost). If you change the port, update SPOTIFY_REDIRECT_URI to match.
3. Copy the Client ID. (The Client Secret is not required.)

Installation

git clone <this-repo> spotify-mcp
cd spotify-mcp

# with uv (recommended)
uv sync

# or with pip
python -m venv .venv && source .venv/bin/activate
pip install -e .

Configuration

Set your Client ID (and optionally the redirect URI) as environment variables. For local testing you can copy .env.example to .env, but MCP clients pass these via their config env block (shown below).

Variable	Required	Default	Notes
`SPOTIFY_CLIENT_ID`	✅	—	From your Spotify app dashboard.
`SPOTIFY_CLIENT_SECRET`	—	—	Optional. If set, uses the classic Authorization Code flow instead of PKCE.
`SPOTIFY_REDIRECT_URI`	—	`http://127.0.0.1:8888/callback`	Must exactly match a redirect URI on your app.
`SPOTIFY_MCP_CACHE`	—	`~/.spotify-mcp/token.json`	Where OAuth tokens are cached.
`RECCOBEATS_BASE_URL`	—	`https://api.reccobeats.com`	Base URL for the `get_audio_features` provider.
`LRCLIB_BASE_URL`	—	`https://lrclib.net`	Base URL for the `find_choruses` lyrics provider.

Authenticate first (recommended)

spotify-mcp auth        # opens a browser to sign in
spotify-mcp status      # confirm you're authenticated

You can also trigger this later from within any MCP client by calling the authenticate tool.

Using with Claude Code

claude mcp add spotify \
  --env SPOTIFY_CLIENT_ID=your_client_id_here \
  -- spotify-mcp

Or add it to your MCP config JSON directly:

{
  "mcpServers": {
    "spotify": {
      "command": "spotify-mcp",
      "env": {
        "SPOTIFY_CLIENT_ID": "your_client_id_here"
      }
    }
  }
}

If spotify-mcp isn't on your PATH, use the full interpreter path instead, e.g. "command": "/path/to/spotify-mcp/.venv/bin/spotify-mcp", or "command": "uv" with "args": ["run", "spotify-mcp"] and a cwd.

Using with Coworker (or other MCP clients)

Any MCP client that launches a stdio server works. Point it at the spotify-mcp command (or python -m spotify_mcp) with SPOTIFY_CLIENT_ID in the environment:

{
  "mcpServers": {
    "spotify": {
      "command": "spotify-mcp",
      "env": { "SPOTIFY_CLIENT_ID": "your_client_id_here" }
    }
  }
}

Then just ask, e.g.:

"Search Spotify for upbeat indie tracks from 2019."
"Show me the songs in my Focus playlist."
"Create a private playlist called Roadtrip and add these five songs."
"How many choruses does Don't Start Now have, and how long is each one?"
"For every song in my Spin Tuesday playlist, list the chorus timings."

Scopes requested

The server requests the scopes needed for its tools: user-read-private, user-read-email, playlist-read-private, playlist-read-collaborative, playlist-modify-private, playlist-modify-public.

Security notes

OAuth tokens are stored locally at SPOTIFY_MCP_CACHE with 0600 permissions and are git-ignored. Never commit them.
PKCE means no client secret is stored on disk or passed around.
The server only calls Spotify's official API endpoints over HTTPS.

Development

# Run the server over stdio (what MCP clients invoke)
spotify-mcp

# Or as a module
python -m spotify_mcp

# Run the tests
uv run pytest

Project layout:

src/spotify_mcp/
  auth.py           # OAuth (PKCE) flow, token cache & refresh
  client.py         # Spotify Web API wrapper + response trimming
  audio_features.py # Tempo/key/energy via ReccoBeats (Spotify's is deprecated)
  structure.py      # Chorus/section detection from LRCLIB synced lyrics
  server.py         # FastMCP server and tool definitions
  __main__.py       # CLI: run server / auth / status
tests/              # Unit + stub-server tests (no network needed)

License

MIT

Available Tools

10 tools

add_tracks_to_playlistA

Add one or more songs to an existing playlist.

Args: playlist_id: A Spotify playlist ID, URI, or URL. track_uris: List of track IDs, spotify:track:... URIs, or track URLs. position: Optional zero-based index to insert at (defaults to the end).

ParametersJSON Schema

Name	Required	Description	Default
`position`	No
`track_uris`	Yes
`playlist_id`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It states it adds tracks (mutation), mentions accepted input formats, and default behavior for position. It does not cover auth requirements, rate limits, error handling, or max tracks, which would improve transparency.

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 extremely concise: one sentence for purpose, then a bullet-style list for args. No extraneous words, and all information is front-loaded.

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 tool with 3 params, no annotations, and no output schema, the description covers purpose and parameter details well. It omits return value and error scenarios, but the core functionality is clear. A minor gap prevents a perfect score.

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 the description fully compensates. It explains each parameter: playlist_id accepts ID, URI, or URL; track_uris are list of IDs/URIs/URLs; position is optional zero-based index defaulting to end. This adds critical meaning beyond the schema's type-only info.

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 action: 'Add one or more songs to an existing playlist.' It uses a specific verb and resource, distinguishing it from sibling tools like create_playlist (create new) or get_playlist (retrieve).

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 explains how to use the tool: required arguments and optional position. However, it lacks explicit guidance on when not to use it or alternatives, such as noting that the playlist must already exist (as opposed to creating one).

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

authenticateA

Run this once before using the other tools. Tokens are cached locally and refreshed automatically, so you normally only need to authenticate a single time per machine.

Args: force: If true, force Spotify to re-show the consent screen (useful to switch accounts or re-grant scopes).

ParametersJSON Schema

Name	Required	Description	Default
`force`	No

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. Discloses OAuth flow, browser interaction, token caching, auto-refresh, and force parameter effect – very transparent.

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?

Well-structured with intro, usage note, and parameter description. Minor redundancy ('normally only need to authenticate a single time' could be tighter) but good.

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?

Complete for a simple one-param tool with no output schema: covers purpose, when to run, token lifecycle, and parameter semantics. No gaps.

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?

Single parameter 'force' is described with context: forces consent screen to switch accounts or re-grant scopes. Schema coverage is 0% but description fully compensates.

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?

Clearly states 'Sign in to Spotify via OAuth (opens a browser window)' – a specific verb-resource pair. Distinguishes from sibling auth_status by being the actual login action.

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?

Explicitly says 'Run this once before using the other tools' and explains token caching, indicating single-use. Missing when-not-to-use but adequate for an authentication tool.

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

auth_statusA

Report whether the server is currently authenticated with Spotify.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Description implies a read-only check with no side effects. No annotations exist, but the description covers the essential behavior.

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?

Single sentence, no wasted words. Perfectly concise.

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?

Given no parameters and a simple boolean return, the description is fully adequate. No additional details needed.

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?

No parameters, so baseline 4 applies since schema coverage is 100%. Description adds nothing beyond schema, which is sufficient.

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 reports authentication status, which is a specific verb+resource. It distinguishes from siblings like 'authenticate' which performs login.

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?

While no explicit when-to-use or exclusions, the context implies using this to check auth state before operations. For a zero-parameter tool, this is adequate.

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

create_playlistA

Create a new playlist for the signed-in user.

Args: name: The playlist name. public: Whether the playlist is public. Defaults to false (private). description: Optional playlist description. collaborative: If true, others can edit it (forces the playlist private). track_uris: Optional list of track IDs/URIs/URLs to add on creation.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`public`	No
`track_uris`	No
`description`	No
`collaborative`	No

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses behavioral details: defaults to private, collaborative forces private, can add tracks on creation. No contradictory statements.

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 clear and front-loaded with the main purpose. The 'Args:' section is slightly verbose but adds value. No wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameter details and constraints well, but does not mention the return value (e.g., the created playlist object). Given no output schema, this omission reduces completeness slightly.

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?

Input schema has 0% description coverage, but the description explains every parameter, including defaults and interactions (e.g., collaborative forces private). This adds substantial meaning beyond schema titles.

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 'Create a new playlist for the signed-in user.' with a specific verb and resource, distinguishing it from sibling tools like add_tracks_to_playlist (adds tracks) and get_playlist (reads).

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 implies usage for creating a playlist, but does not explicitly state when not to use it or suggest alternatives among siblings. The context is clear for a straightforward creation tool.

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

get_currently_playingA

Show the track currently playing on the user's Spotify account (if any).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It indicates a read operation but fails to disclose important behavior such as the need for prior authentication (sibling authenticate tool exists), the return format (track object or null), or any side effects. More detail is needed for a complete behavioral picture.

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 a single 12-word sentence with no wasted words. It is front-loaded and immediately conveys the tool's purpose, achieving perfect conciseness.

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 simple tool with no parameters and no output schema, the description covers the essential purpose. However, it could be improved by explicitly stating the return value (e.g., 'Returns a track object or null'). The 'if any' hints at null but does not specify the object structure.

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?

The tool has zero parameters, and schema coverage is 100% (since there are none). The baseline for no parameters is 4. The description adds no parameter info, which is appropriate because there are none to explain.

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 verb 'Show' and the resource 'track currently playing', with scope on the user's Spotify account. It distinguishes from siblings like get_track (specific track) and get_playlist (playlist), making the tool's purpose unambiguous.

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 for checking current playback and mentions the conditional 'if any', but it does not explicitly state when to use this tool versus alternatives (e.g., get_track) or provide any exclusions or prerequisites like authentication.

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

get_current_userA

Get the profile of the signed-in Spotify user (id, name, country, etc.).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

The description discloses that the tool returns the user's profile with id, name, country, and other unspecified fields ('etc.'). However, it does not mention behavioral traits like authentication requirements, error conditions (e.g., no user signed in), or any side effects. Given the lack of annotations, the description carries the full burden but provides only partial transparency.

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 a single, clear sentence that directly states the tool's function and examples of returned data. It contains no unnecessary words or filler, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description provides enough information for basic understanding but lacks details like authentication requirements, potential errors, or a full list of return fields (it ends with 'etc.'). With no output schema, the description should be more complete to cover these gaps.

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?

With zero parameters, the input schema is fully covered by the description (100% coverage trivially). The description does not need to add parameter details, and the baseline for 0-parameter tools is 4, which is appropriate here.

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 retrieves the profile of the signed-in Spotify user, listing example fields like id, name, and country. It uses a specific verb ('Get') and resource ('profile'), and it distinguishes itself from sibling tools like get_currently_playing or get_playlist, which have different purposes.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The purpose is implied by the name and description, but there is no mention of exclusion or alternatives, such as using authenticate or auth_status for authentication-related tasks.

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

get_playlistA

Get a playlist's details and its tracks.

Args: playlist_id: A Spotify playlist ID, spotify:playlist:... URI, or open.spotify.com playlist URL. tracks_limit: Max number of tracks to include (default 100). If the playlist has more, tracks_truncated will be true.

ParametersJSON Schema

Name	Required	Description	Default
`playlist_id`	Yes
`tracks_limit`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the output includes details and tracks with potential truncation (tracks_truncated flag), and documents acceptable playlist_id formats. It does not cover authentication or rate limits, but the core behavior is transparent.

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 extremely concise with two short paragraphs. The first sentence states the purpose, followed by parameter details. Every sentence adds value; no fluff.

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?

Given no output schema, the description outlines the output (details and tracks) and mentions the truncation behavior. However, 'details' is somewhat vague and could be more specific (e.g., includes name, owner, etc.). Overall, it covers the essential context for a get playlist tool.

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?

The description adds significant meaning beyond the input schema, which has 0% coverage. It explains playlist_id can be a Spotify ID, URI, or URL, and tracks_limit max with default 100 and that exceeding it sets tracks_truncated to true. This fully clarifies both parameters.

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 retrieves a playlist's details and its tracks, using specific verbs and resource. It distinguishes itself from siblings like list_my_playlists (listing all playlists) and get_track (single track) by focusing on one playlist.

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 when a user has a playlist ID and wants its details and tracks, but it does not explicitly mention when to use this tool over alternatives (e.g., list_my_playlists for all playlists, get_track for a single track). No exclusions or when-not-to-use guidance.

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

get_trackA

Get detailed information about a single song.

Args: track_id: A Spotify track ID, spotify:track:... URI, or open.spotify.com track URL.

ParametersJSON Schema

Name	Required	Description	Default
`track_id`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description only states the function is a read operation ('Get detailed information'). It does not disclose any behavioral traits such as authentication requirements, rate limits, or response format. However, for a simple get, this is minimally adequate.

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 extremely concise: two sentences plus a single parameter explanation. Every sentence is purposeful, and the structure is clear.

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 simple retrieval tool with one parameter, the description provides necessary details about parameter format. It lacks description of the response, but since no output schema exists and the return is presumably a standard track object, completeness is high.

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?

The input schema has 0% description coverage, but the tool description fully explains the parameter 'track_id' with valid formats (ID, URI, URL), adding significant value 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 verb 'Get' and the resource 'detailed information about a single song', which is specific and distinguishes it from sibling tools like get_playlist or search.

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 for retrieving a single track, but does not explicitly state when to use this over alternatives (e.g., search for finding tracks, get_playlist for playlists). No exclusions or prerequisites are mentioned.

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

list_my_playlistsA

List the playlists owned or followed by the signed-in user.

Args: limit: Number of playlists to return (1-50). Defaults to 20. offset: Index to start from, for paging through large libraries.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as safety (read-only), auth requirements, rate limits, or pagination behavior beyond parameter hints. The action is implied read, but not explicitly stated.

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 concise with a single line for purpose and an Args section. No redundant information; each sentence adds value. Front-loaded with the key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and no output schema, the description covers parameters and hints at pagination. However, it lacks details on returned fields, error states, or any advanced behavior, which is acceptable but leaves room for improvement.

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?

The schema has 0% description coverage, but the description adds meaning beyond defaults: limit range (1-50) and default (20), offset as pagination index. It clarifies what the parameters do, which is sufficient for a simple tool.

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 lists playlists owned or followed by the signed-in user, with a specific verb and resource. It distinguishes from siblings like get_playlist (singular) and search (which is broader).

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 when needing the user's playlists, but does not explicitly state when not to use it or compare it to alternatives like search or get_playlist. No exclusions or context are provided.

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

searchA

Search the Spotify catalog.

Args: query: Search text. Supports Spotify field filters, e.g. artist:radiohead track:creep or year:2020 genre:jazz. types: Comma-separated result types to return. Any of: track, album, artist, playlist. Defaults to track. limit: Max results per type (1-50). Defaults to 10.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`types`	No	track

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It explains parameter usage but does not mention authentication requirements, return format, or pagination, leaving significant gaps for an agent.

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 concise and well-structured with an args list and concrete examples. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema, the description fails to explain the return format, pagination, or authentication needs. However, it does cover parameter details sufficiently for basic usage. It is adequate but not 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?

Despite 0% schema description coverage, the description adds substantial meaning: it explains the query's field filter syntax with examples, defines types as comma-separated list of specific result types, and clarifies limit as max per type. This goes well 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 'Search the Spotify catalog,' which is a specific verb+resource combination. It effectively distinguishes from sibling tools like create_playlist or get_track.

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 for searching the catalog but does not explicitly state when to use vs alternatives, nor provides any exclusion criteria or prerequisite conditions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jul 4, 2026
- First observedadd_tracks_to_playlist
- First observedauth_status
- First observedauthenticate
- First observedcreate_playlist
- First observedget_current_user
- First observedget_currently_playing
- First observedget_playlist
- First observedget_track
- First observedlist_my_playlists
- First observedsearch

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: authentication, user info, search, playback status, and playlist management. No overlapping functionality, and descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_playlist, get_currently_playing, add_tracks_to_playlist), making the API predictable and easy to navigate.

Tool Count5/5

10 tools provide a well-scoped set for a music assistant: authentication, user profile, search, playback info, and playlist CRUD. This covers essential interactions without being excessive or insufficient.

Completeness4/5

Core workflows are covered (auth, search, playlist management). Minor gaps exist (e.g., removing tracks from playlists, updating playlist metadata, playback control), but most agents will find the set sufficient for common tasks.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Spotify
io.github.akutishevsky
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Entertainment & Media App Automation
2
spotify D
com.jojapi
Spotify: Spotify Data API for Millions of songs & podcasts, artists, albums, playlists and more.
Entertainment & Media Search
371
Spotify B
io.github.pipeworx-io
Spotify MCP — Web API via client_credentials OAuth
Entertainment & Media Search
372
musicbrainz-mcp-server A
io.github.cyanheads
Search MusicBrainz artists, releases, works, labels; resolve ISRC/ISWC/barcode; fetch cover art.
Entertainment & Media Search Open Data
1021

Related MCP Servers

MCP Spotify Server
Entertainment & Media Search
superseoworld
A
license
B
quality
D
maintenance
Enables interaction with Spotify's music catalog via the Spotify Web API, supporting searches, artist information retrieval, playlist management, and automatic token handling.
Updated 2 years ago (2025-03-03 12:50 UTC)
26
33
23
MIT
Spotify Streamable MCP Server
Cloud Platforms Audio Processing
iceener
A
license
Not graded
quality
B
maintenance
Enables control of Spotify through natural language by searching the catalog, managing playback and devices, controlling playlists, and managing saved songs. Includes OAuth authentication and streamable HTTP transport for remote connectivity.
Updated 11 days ago (2026-08-26 08:16 UTC)
22
79
ISC
Spotify MCP Server
Entertainment & Media App Automation
EvansLR
F
license
Not graded
quality
D
maintenance
Enables control of Spotify playback through OAuth authentication, including play/pause, track navigation, volume control, device management, and searching/playing songs by artist or track name.
Updated 9 months ago (2025-12-03 03:30 UTC)
1
-
Spotify API MCP
Entertainment & Media Search App Automation
fisknils
F
license
A
quality
D
maintenance
Enables interaction with Spotify through OAuth 2.0 authentication, supporting search for tracks/artists/albums/playlists, user profile access, and playlist management including creation and adding tracks.
Updated a year ago (2025-07-05 15:27 UTC)
6
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/abenke/spotify-mcp'

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

Spotify MCP

Features

How it works

Audio features (tempo/BPM, key, energy, danceability)

Chorus detection (find_choruses)

Prerequisites

Installation

Configuration

Authenticate first (recommended)

Using with Claude Code

Using with Coworker (or other MCP clients)

Scopes requested

Security notes

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Chorus detection (`find_choruses`)