Ein Model Context Protocol (MCP)-Server, der Claude mit Spotify verbindet. Steuern Sie Ihre Spotify-Wiedergabe, suchen Sie Musik, verwalten Sie Wiedergabelisten und mehr – alles durch natürliche Konversation mit Claude.
Fork-Hinweis: Dieses Projekt ist ein Fork von varunneal/spotify-mcp und wurde für die Änderungen der Spotify Web API vom Februar 2026 aktualisiert. Erstellt und gewartet mit Claude Code.
spotipy entfernt -- verwendet httpx async direkt (natives Async, kein asyncio.to_thread-Wrapping)
Einzelnes Modul -- server.py, spotify_api.py, utils.py wurden in einer Datei zusammengefasst
FastMCP -- saubere @mcp.tool()-Dekoratoren anstelle von manuellem ToolModel + match/case-Routing
2 Abhängigkeiten -- nur mcp + httpx (vorher mcp + spotipy + python-dotenv)
Explizites OAuth -- spotify-mcp --auth für die Ersteinrichtung, automatische Aktualisierung bei nachfolgender Verwendung
Wiedergabe starten, pausieren und überspringen
Suche nach Titeln, Alben, Künstlern und Wiedergabelisten
Detaillierte Informationen zu jedem Spotify-Element abrufen
Wiedergabewarteschlange verwalten
Vollständiges CRUD für Wiedergabelisten (Titel erstellen, lesen, aktualisieren, löschen)
Gelikte/gespeicherte Songs mit optionaler Genre-Anreicherung abrufen
Angepasst an die Spotify-API-Änderungen vom Februar 2026
Related MCP server: Spotify MCP Server
Claude <--MCP (stdio)--> spotify-mcp <--httpx async--> Spotify Web APIClaude sendet Tool-Aufrufe über das MCP-Protokoll
Der Server übersetzt diese in Spotify Web API-Anfragen mittels httpx
OAuth-Token werden automatisch aktualisiert; Erstauthentifizierung über spotify-mcp --auth
Ergebnisse werden in präzises JSON geparst und an Claude zurückgegeben
Tool | Aktionen | Beschreibung |
|
| Steuerung der Musikwiedergabe und Lautstärke |
| -- | Suche nach Titeln, Alben, Künstlern, Wiedergabelisten |
|
| Wiedergabewarteschlange anzeigen und verwalten |
| -- | Detaillierte Elementinformationen per Spotify-URI abrufen |
|
| Vollständige Verwaltung von Wiedergabelisten |
|
| Gespeicherte Songs verwalten und Bibliothek prüfen |
| -- | Kürzlich gespielte Titel mit Zeitstempeln abrufen |
|
| Geräte auflisten und Wiedergabe übertragen |
src/spotify_mcp/
__init__.py # Entry point (stdio / --auth)
server.py # FastMCP server, API client, parsers — all in onePython 3.12+
Spotify Premium-Konto (erforderlich für den Dev-Mode-API-Zugriff seit Februar 2026)
Spotify Developer App-Anmeldedaten
Gehen Sie zu developer.spotify.com/dashboard
Erstellen Sie eine neue App
Setzen Sie den Redirect-URI auf http://127.0.0.1:8080/callback
Notieren Sie sich Ihre Client ID und Ihr Client Secret
Wichtig (Februar 2026): Apps im Dev-Mode sind auf 5 autorisierte Benutzer begrenzt und erfordern, dass der App-Besitzer Spotify Premium besitzt.
Führen Sie den Auth-Flow einmal aus, um Ihr OAuth-Token zu erhalten:
SPOTIFY_CLIENT_ID=your_id SPOTIFY_CLIENT_SECRET=your_secret uv run spotify-mcp --authDies öffnet einen Browser für den Spotify-Login und speichert das Token anschließend unter ~/.spotify_mcp_cache.json.
git clone https://github.com/verIdyia/spotify-mcp.gitFügen Sie dies zu Ihrer MCP-Konfiguration hinzu (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 | Erforderlich | Standard | Beschreibung |
| Ja | -- | Spotify App Client ID |
| Ja | -- | Spotify App Client Secret |
| Nein |
| OAuth Redirect-URI |
| Nein |
| Pfad zur Token-Cache-Datei |
Erster Start: Führen Sie spotify-mcp --auth aus, um den OAuth-Flow abzuschließen, bevor Sie ihn mit einem MCP-Client verwenden
Token abgelaufen: Token werden automatisch aktualisiert. Falls Probleme bestehen bleiben, führen Sie --auth erneut aus
Kein aktives Gerät: Stellen Sie sicher, dass Spotify geöffnet ist und auf mindestens einem Gerät spielt
Stellen Sie sicher, dass uv aktualisiert ist -- Version >=0.54 empfohlen
Starten Sie den MCP Inspector:
npx @modelcontextprotocol/inspector uv --directory /path/to/spotify-mcp run spotify-mcpÄnderung | Auswirkung | Status |
Such- | Weniger Ergebnisse pro Suche | Angepasst |
Playlist-Endpunkte | Endpunkt-URLs geändert | Angepasst |
Antwortfeld | Parsing aktualisiert | Angepasst |
Batch-GET-Endpunkte entfernt | Muss einzeln abgerufen werden | Angepasst |
| Nicht mehr verfügbar | Behandelt |
Dev-Mode: 5-Benutzer-Limit, Premium erforderlich | Zugriffsbeschränkung | Dokumentiert |
Ursprüngliches Projekt: varunneal/spotify-mcp von Varun Srivastava (MIT-Lizenz)
Ursprüngliche Mitwirkende: @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj, @JJGO und andere
Gewartet mit: Claude Code (Anthropic)
MIT-Lizenz -- siehe LICENSE für 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.
v0.3.0SpotifyGetInfoSpotifyLikedSongsSpotifyPlaybackSpotifyPlaylistSpotifyQueueSpotifySearchScored across 6 tools
Each 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.
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.
