The spotify-mcp server integrates Spotify's Web API with Claude, enabling comprehensive Spotify control through natural conversation.
Playback Control (SpotifyPlayback): Get current playback status, start/resume (optionally with a specific URI), pause, or skip tracks (with configurable skip count)
Music Search (SpotifySearch): Find tracks, albums, artists, or playlists by query, up to 10 results per Spotify API constraints
Queue Management (SpotifyQueue): View the current playback queue or add specific tracks by ID
Item Info Lookup (SpotifyGetInfo): Retrieve detailed information about any Spotify item (track, album, artist, playlist) via its URI
Playlist Management (SpotifyPlaylist): Full CRUD — list playlists, get tracks, add/remove tracks, update name/description/visibility, create, or delete playlists
Liked Songs Access (SpotifyLikedSongs): Retrieve your saved songs with optional genre enrichment and configurable result limit
Authentication uses OAuth with auto-refreshing tokens after initial setup via --auth.
Provides tools to control music playback, search for tracks, albums, and artists, manage the play queue, and perform full playlist management including creating, updating, and deleting playlists.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spotify-mcp play my 'Deep Focus' playlist and skip to the next track"
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.
A Model Context Protocol (MCP) server that connects Claude with Spotify. Control your Spotify playback, search music, manage playlists, and more -- all through natural conversation with Claude.
Fork Notice: This project is forked from varunneal/spotify-mcp and updated for the Spotify Web API February 2026 changes. Built and maintained with Claude Code.
Dropped spotipy -- uses httpx async directly (native async, no asyncio.to_thread wrapping)
Single module -- server.py, spotify_api.py, utils.py consolidated into one file
FastMCP -- clean @mcp.tool() decorators instead of manual ToolModel + match/case routing
2 dependencies -- only mcp + httpx (was mcp + spotipy + python-dotenv)
Explicit OAuth -- spotify-mcp --auth for initial setup, auto-refresh on subsequent use
Start, pause, and skip playback
Search for tracks, albums, artists, and playlists
Get detailed info about any Spotify item
Manage the playback queue
Full playlist CRUD (create, read, update, delete tracks)
Retrieve liked/saved songs with optional genre enrichment
Adapted for Spotify Feb 2026 API changes
Related MCP server: Spotify MCP Server
Claude <--MCP (stdio)--> spotify-mcp <--httpx async--> Spotify Web APIClaude sends tool calls via the MCP protocol
The server translates them into Spotify Web API requests using httpx
OAuth tokens auto-refresh; initial auth via spotify-mcp --auth
Results are parsed into concise JSON and returned to Claude
Tool | Actions | Description |
|
| Control music playback and volume |
| -- | Search tracks, albums, artists, playlists |
|
| View and manage play queue |
| -- | Get detailed item info by Spotify URI |
|
| Full playlist management |
|
| Manage saved songs and check library |
| -- | Get recently played tracks with timestamps |
|
| List devices and transfer playback |
src/spotify_mcp/
__init__.py # Entry point (stdio / --auth)
server.py # FastMCP server, API client, parsers — all in onePython 3.12+
Spotify Premium account (required for Dev Mode API access since Feb 2026)
Spotify Developer App credentials
Create a new app
Set redirect URI to http://127.0.0.1:8080/callback
Note your Client ID and Client Secret
Important (Feb 2026): Dev Mode apps are limited to 5 authorized users and require the app owner to have Spotify Premium.
Run the auth flow once to get your OAuth token:
SPOTIFY_CLIENT_ID=your_id SPOTIFY_CLIENT_SECRET=your_secret uv run spotify-mcp --authThis opens a browser for Spotify login, then saves the token to ~/.spotify_mcp_cache.json.
git clone https://github.com/verIdyia/spotify-mcp.gitAdd to your MCP config (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"spotify": {
"command": "uv",
"args": [
"--directory",
"/path/to/spotify-mcp",
"run",
"spotify-mcp"
],
"env": {
"SPOTIFY_CLIENT_ID": "your_client_id",
"SPOTIFY_CLIENT_SECRET": "your_client_secret",
"SPOTIFY_REDIRECT_URI": "http://127.0.0.1:8080/callback"
}
}
}
}{
"mcpServers": {
"spotify": {
"command": "uvx",
"args": [
"--python", "3.12",
"--from", "git+https://github.com/verIdyia/spotify-mcp",
"spotify-mcp"
],
"env": {
"SPOTIFY_CLIENT_ID": "your_client_id",
"SPOTIFY_CLIENT_SECRET": "your_client_secret",
"SPOTIFY_REDIRECT_URI": "http://127.0.0.1:8080/callback"
}
}
}
}Variable | Required | Default | Description |
| Yes | -- | Spotify app Client ID |
| Yes | -- | Spotify app Client Secret |
| No |
| OAuth redirect URI |
| No |
| Token cache file path |
First run: Run spotify-mcp --auth to complete the OAuth flow before using with an MCP client
Token expired: Tokens auto-refresh. If issues persist, re-run --auth
No active device: Make sure Spotify is open and playing on at least one device
Make sure uv is updated -- version >=0.54 recommended
Launch the MCP Inspector:
npx @modelcontextprotocol/inspector uv --directory /path/to/spotify-mcp run spotify-mcpChange | Impact | Status |
Search | Fewer results per search | Adapted |
Playlist endpoints | Endpoint URLs changed | Adapted |
Response field | Parsing updated | Adapted |
Batch GET endpoints removed | Must fetch individually | Adapted |
| No longer available | Handled |
Dev Mode: 5 user limit, Premium required | Access restriction | Documented |
Original project: varunneal/spotify-mcp by Varun Srivastava (MIT License)
Original contributors: @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj, @JJGO and others
Maintained with: Claude Code (Anthropic)
MIT License -- see LICENSE for details.
Get detailed information about a Spotify item...
| Name | Required | Description | Default |
|---|---|---|---|
| item_uri | Yes | URI of the item to get information about. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get detailed information') without mentioning permissions, rate limits, response format, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. However, it could be more front-loaded with key details (e.g., item types) to improve structure, but it avoids redundancy and waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral traits like authentication needs. For a tool with no structured support, the description should compensate more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'item_uri' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as URI format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a Spotify item'), making the purpose understandable. However, it doesn't specify what type of 'item' (track, album, artist, playlist) or differentiate from sibling tools like SpotifySearch or SpotifyPlaylist, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like SpotifySearch (for finding items) or SpotifyPlaylist (for playlist-specific info), nor does it specify prerequisites or contexts for usage, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's liked (saved) songs from Spotify library.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: 'get' or 'get_with_genres'. | |
| limit | No | Max number of songs to return. 0 for all songs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation but doesn't mention whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool accessing user library data with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (song objects, IDs, metadata), whether authentication is required, or how it differs from sibling tools. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents both parameters (action and limit). The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'user's liked (saved) songs from Spotify library', making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like SpotifyPlaylist or SpotifyGetInfo, which might also retrieve user content from Spotify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like SpotifyPlaylist (which might handle playlist songs) or SpotifyGetInfo (which could retrieve other user data). There's no mention of prerequisites, authentication needs, or specific use cases that would help an agent choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manages the current playback...
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: 'get', 'start', 'pause' or 'skip'. | |
| spotify_uri | No | Spotify uri of item to play... | |
| num_skips | No | Number of tracks to skip for `skip` action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Manages' implies mutation capabilities, but it doesn't disclose behavioral traits like authentication needs, rate limits, or side effects. It lacks details on what 'start' or 'pause' actually do in practice, leaving gaps in understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment ('Manages the current playback...') that is too brief and lacks structure. It's front-loaded but under-specified, failing to provide essential details. While concise, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or operational constraints. For a tool with 3 parameters and mutation capabilities, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters well. The description adds no additional meaning beyond the schema, which already explains actions, URI usage, and skip count. Baseline is 3 as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manages the current playback...' states the general purpose but is vague. It mentions the resource ('playback') but lacks specificity about what management entails. It doesn't clearly distinguish from siblings like SpotifyQueue or SpotifyPlaylist, which also involve playback control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. For example, it doesn't clarify if this requires an active device or how it differs from SpotifyQueue for skipping tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Spotify playlists.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: 'get', 'get_tracks', 'add_tracks', 'remove_tracks', 'change_details', 'create', 'delete'. | |
| playlist_id | No | ID of the playlist to manage. | |
| track_ids | No | List of track IDs to add/remove. | |
| name | No | Name for the playlist | |
| description | No | Description for the playlist. | |
| public | No | Whether the playlist should be public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. 'Manage' implies both read and write operations, but it doesn't disclose permissions needed, rate limits, side effects (e.g., playlist deletion), or response formats. This is inadequate for a multi-action tool with potential destructive operations like 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Manage Spotify playlists.') with no wasted words. It's front-loaded and to the point, though this brevity contributes to gaps in other dimensions. Every sentence (here, just one) earns its place by stating the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multiple actions including destructive ones like 'delete'), no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral nuances, leaving critical gaps for an AI agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the schema's details. Baseline 3 is appropriate as the schema handles parameter semantics effectively, though the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage Spotify playlists' states the general purpose (verb+resource) but is vague about what 'manage' entails. It doesn't differentiate from sibling tools like SpotifyLikedSongs or SpotifyQueue, which also handle playlist-related content. The description is functional but lacks specificity about the scope of operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), exclusions, or comparisons to siblings like SpotifyGetInfo or SpotifyPlayback. Usage is implied through the action parameter but not explicitly stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the playback queue - get the queue or add tracks.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: 'add' or 'get'. | |
| track_id | No | Track ID to add to queue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'manage' and actions but doesn't describe key traits like whether this requires active playback, authentication needs, rate limits, or what happens on errors. For a tool with potential side effects (adding tracks), this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. Every word earns its place, with no redundant information or fluff, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a queue management tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values for 'get' actions, error handling, or behavioral constraints. For a tool that could involve mutations (adding tracks), more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (action and track_id). The description adds minimal value beyond the schema, as it only reiterates the actions ('get' or 'add') without providing additional context like format examples or usage nuances. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage the playback queue - get the queue or add tracks.' It specifies the verb ('manage') and resource ('playback queue') with two concrete actions. However, it doesn't distinguish this from sibling tools like SpotifyPlayback or SpotifyPlaylist, which might also involve queue management, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'get the queue or add tracks' but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this is for active playback only or how it relates to SpotifyPlayback. Without such context, the agent has limited direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for tracks, albums, artists, or playlists on Spotify.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | query term | |
| qtype | No | Type of items to search for | track |
| limit | No | Maximum number of items to return (max 10 per Spotify API limit) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching but doesn't cover critical aspects like authentication needs, rate limits, response format, or error handling. This is a significant gap for a tool that interacts with an external API like Spotify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and easy to parse, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral traits like API constraints, authentication, or response format, which are crucial for a search tool interacting with Spotify's API. This leaves gaps in understanding how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (query, qtype, limit) with their purposes and defaults. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for adequate but not enhanced documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for') and resources ('tracks, albums, artists, or playlists on Spotify'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like SpotifyGetInfo or SpotifyPlaylist, which might also involve searching or retrieving content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like SpotifyGetInfo or SpotifyPlaylist. It lacks context about specific use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the general search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0SpotifyGetInfoSpotifyLikedSongsSpotifyPlaybackSpotifyPlaylistSpotifyQueueSpotifySearchEach tool has a clearly distinct purpose targeting different Spotify resources: GetInfo for item details, LikedSongs for saved songs, Playback for current playback control, Playlist for playlist management, Queue for queue operations, and Search for finding content. There is no overlap or ambiguity between these functions.
All tools follow a consistent 'Spotify' prefix with descriptive noun-based naming (e.g., SpotifyGetInfo, SpotifyPlaylist). The pattern is uniform across all six tools, making them easily identifiable and predictable.
With 6 tools, this server is well-scoped for Spotify integration, covering key areas like playback, playlists, search, and user library. Each tool serves a specific, necessary function without bloat or redundancy.
The toolset covers core Spotify functionalities including search, playback control, playlist management, and user data access. Minor gaps might include operations like following artists or managing user profile settings, but the provided tools support most common workflows effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Producer/Riffusion AI music generation
MCP server for Suno AI music generation, lyrics, and covers
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/verIdyia/spotify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
