一个将 Claude 与 Spotify 连接起来的 模型上下文协议 (MCP) 服务器。通过与 Claude 的自然对话，控制你的 Spotify 播放、搜索音乐、管理播放列表等。
分支说明：本项目派生自 varunneal/spotify-mcp，并针对 2026 年 2 月的 Spotify Web API 变更进行了更新。使用 Claude Code 构建和维护。
弃用 spotipy -- 直接使用 httpx 异步请求（原生异步，无需 asyncio.to_thread 包装）
单一模块 -- 将 server.py、spotify_api.py、utils.py 合并为一个文件
FastMCP -- 使用简洁的 @mcp.tool() 装饰器，而非手动 ToolModel + match/case 路由
2 个依赖项 -- 仅 mcp + httpx（原为 mcp + spotipy + python-dotenv）
显式 OAuth -- 使用 spotify-mcp --auth 进行初始设置，后续使用时自动刷新
开始、暂停和跳过播放
搜索曲目、专辑、艺术家和播放列表
获取有关任何 Spotify 项目的详细信息
管理播放队列
完整的播放列表 CRUD（创建、读取、更新、删除曲目）
获取已点赞/保存的歌曲，并可选择进行流派丰富
适配 Spotify 2026 年 2 月的 API 变更
Related MCP server: Spotify MCP Server
Claude <--MCP (stdio)--> spotify-mcp <--httpx async--> Spotify Web APIClaude 通过 MCP 协议发送工具调用
服务器使用 httpx 将其转换为 Spotify Web API 请求
OAuth 令牌自动刷新；初始认证通过 spotify-mcp --auth 完成
结果被解析为简洁的 JSON 并返回给 Claude
工具 | 操作 | 描述 |
|
| 控制音乐播放和音量 |
| -- | 搜索曲目、专辑、艺术家、播放列表 |
|
| 查看和管理播放队列 |
| -- | 通过 Spotify URI 获取详细项目信息 |
|
| 完整的播放列表管理 |
|
| 管理已保存的歌曲并检查库 |
| -- | 获取带有时间戳的最近播放曲目 |
|
| 列出设备并传输播放 |
src/spotify_mcp/
__init__.py # Entry point (stdio / --auth)
server.py # FastMCP server, API client, parsers — all in onePython 3.12+
Spotify Premium 账户（自 2026 年 2 月起，开发模式 API 访问必需）
Spotify 开发者应用凭据
创建一个新应用
将重定向 URI 设置为 http://127.0.0.1:8080/callback
记下你的 Client ID 和 Client Secret
重要 (2026 年 2 月)：开发模式应用限制为 5 个授权用户，且要求应用所有者拥有 Spotify Premium。
运行一次认证流程以获取 OAuth 令牌：
SPOTIFY_CLIENT_ID=your_id SPOTIFY_CLIENT_SECRET=your_secret uv run spotify-mcp --auth这将打开浏览器进行 Spotify 登录，然后将令牌保存到 ~/.spotify_mcp_cache.json。
git clone https://github.com/verIdyia/spotify-mcp.git添加到你的 MCP 配置（Claude Desktop、Cursor 等）：
{
"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"
}
}
}
}变量 | 必需 | 默认值 | 描述 |
| 是 | -- | Spotify 应用 Client ID |
| 是 | -- | Spotify 应用 Client Secret |
| 否 |
| OAuth 重定向 URI |
| 否 |
| 令牌缓存文件路径 |
首次运行：在使用 MCP 客户端之前，请运行 spotify-mcp --auth 完成 OAuth 流程
令牌过期：令牌会自动刷新。如果问题仍然存在，请重新运行 --auth
无活动设备：确保 Spotify 已打开并在至少一台设备上播放
确保 uv 已更新 -- 建议版本 >=0.54
启动 MCP Inspector：
npx @modelcontextprotocol/inspector uv --directory /path/to/spotify-mcp run spotify-mcp变更 | 影响 | 状态 |
搜索 | 每次搜索结果减少 | 已适配 |
播放列表端点 | 端点 URL 变更 | 已适配 |
响应字段 | 解析已更新 | 已适配 |
批量 GET 端点移除 | 必须单独获取 | 已适配 |
移除曲目的 | 不再可用 | 已处理 |
开发模式：5 用户限制，需 Premium | 访问限制 | 已记录 |
原始项目：varunneal/spotify-mcp，作者 Varun Srivastava (MIT 许可证)
原始贡献者：@jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj, @JJGO 等
维护工具：Claude Code (Anthropic)
MIT 许可证 -- 详情请参阅 LICENSE。
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.
