Un servidor del Protocolo de Contexto de Modelo (MCP) que conecta Claude con Spotify. Controla tu reproducción de Spotify, busca música, gestiona listas de reproducción y más, todo a través de una conversación natural con Claude.
Aviso de bifurcación: Este proyecto es una bifurcación de varunneal/spotify-mcp y está actualizado para los cambios de la API web de Spotify de febrero de 2026. Creado y mantenido con Claude Code.
Se eliminó spotipy -- utiliza httpx asíncrono directamente (asíncrono nativo, sin envoltorio asyncio.to_thread)
Módulo único -- server.py, spotify_api.py, utils.py consolidados en un solo archivo
FastMCP -- decoradores @mcp.tool() limpios en lugar de ToolModel manual + enrutamiento match/case
2 dependencias -- solo mcp + httpx (antes mcp + spotipy + python-dotenv)
OAuth explícito -- spotify-mcp --auth para la configuración inicial, autorrefresco en usos posteriores
Iniciar, pausar y saltar reproducción
Buscar pistas, álbumes, artistas y listas de reproducción
Obtener información detallada sobre cualquier elemento de Spotify
Gestionar la cola de reproducción
CRUD completo de listas de reproducción (crear, leer, actualizar, eliminar pistas)
Recuperar canciones que te gustan/guardadas con enriquecimiento de género opcional
Adaptado para los cambios de la API de Spotify de febrero de 2026
Related MCP server: Spotify MCP Server
Claude <--MCP (stdio)--> spotify-mcp <--httpx async--> Spotify Web APIClaude envía llamadas a herramientas a través del protocolo MCP
El servidor las traduce en solicitudes a la API web de Spotify usando httpx
Los tokens OAuth se autorrefrescan; autenticación inicial mediante spotify-mcp --auth
Los resultados se analizan en un JSON conciso y se devuelven a Claude
Herramienta | Acciones | Descripción |
|
| Controla la reproducción de música y el volumen |
| -- | Busca pistas, álbumes, artistas, listas de reproducción |
|
| Ver y gestionar la cola de reproducción |
| -- | Obtener información detallada del elemento mediante URI de Spotify |
|
| Gestión completa de listas de reproducción |
|
| Gestionar canciones guardadas y comprobar la biblioteca |
| -- | Obtener pistas reproducidas recientemente con marcas de tiempo |
|
| Listar dispositivos y transferir la reproducción |
src/spotify_mcp/
__init__.py # Entry point (stdio / --auth)
server.py # FastMCP server, API client, parsers — all in onePython 3.12+
Cuenta de Spotify Premium (requerida para el acceso a la API en modo desarrollador desde febrero de 2026)
Credenciales de Aplicación de desarrollador de Spotify
Crea una nueva aplicación
Establece el URI de redirección en http://127.0.0.1:8080/callback
Anota tu ID de cliente y Secreto de cliente
Importante (febrero de 2026): Las aplicaciones en modo desarrollador están limitadas a 5 usuarios autorizados y requieren que el propietario de la aplicación tenga Spotify Premium.
Ejecuta el flujo de autenticación una vez para obtener tu token OAuth:
SPOTIFY_CLIENT_ID=your_id SPOTIFY_CLIENT_SECRET=your_secret uv run spotify-mcp --authEsto abre un navegador para iniciar sesión en Spotify y luego guarda el token en ~/.spotify_mcp_cache.json.
git clone https://github.com/verIdyia/spotify-mcp.gitAñadir a tu configuración de MCP (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 | Requerido | Predeterminado | Descripción |
| Sí | -- | ID de cliente de la aplicación Spotify |
| Sí | -- | Secreto de cliente de la aplicación Spotify |
| No |
| URI de redirección OAuth |
| No |
| Ruta del archivo de caché de tokens |
Primera ejecución: Ejecuta spotify-mcp --auth para completar el flujo OAuth antes de usarlo con un cliente MCP
Token caducado: Los tokens se autorrefrescan. Si los problemas persisten, vuelve a ejecutar --auth
Sin dispositivo activo: Asegúrate de que Spotify esté abierto y reproduciéndose en al menos un dispositivo
Asegúrate de que uv esté actualizado -- se recomienda la versión >=0.54
Inicia el inspector MCP:
npx @modelcontextprotocol/inspector uv --directory /path/to/spotify-mcp run spotify-mcpCambio | Impacto | Estado |
Límite de búsqueda | Menos resultados por búsqueda | Adaptado |
Endpoints de lista de reproducción | Las URLs de los endpoints cambiaron | Adaptado |
Campo de respuesta | Análisis actualizado | Adaptado |
Endpoints GET por lotes eliminados | Se deben obtener individualmente | Adaptado |
Campo | Ya no está disponible | Gestionado |
Modo desarrollador: límite de 5 usuarios, se requiere Premium | Restricción de acceso | Documentado |
Proyecto original: varunneal/spotify-mcp por Varun Srivastava (Licencia MIT)
Colaboradores originales: @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj, @JJGO y otros
Mantenido con: Claude Code (Anthropic)
Licencia MIT -- consulta LICENSE para más detalles.
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.
