ClaudeとSpotifyを接続するModel Context Protocol (MCP)サーバーです。Spotifyの再生制御、音楽検索、プレイリスト管理などを、Claudeとの自然な会話を通じて行えます。
フォークに関する注意: 本プロジェクトはvarunneal/spotify-mcpからフォークされ、2026年2月のSpotify Web APIの変更に対応したものです。Claude Codeを使用して構築・保守されています。
spotipyを廃止 -- httpxの非同期処理を直接使用（ネイティブ非同期、asyncio.to_threadによるラップなし）
シングルモジュール化 -- server.py、spotify_api.py、utils.pyを1つのファイルに統合
FastMCP -- 手動のToolModelやmatch/caseルーティングではなく、クリーンな@mcp.tool()デコレーターを採用
依存関係を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 Developer Appの認証情報
新しいアプリを作成
リダイレクト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.gitMCP設定（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が開いており、少なくとも1つのデバイスで再生中であることを確認してください
uvの更新: バージョン>=0.54を推奨します
MCP Inspectorを起動します：
npx @modelcontextprotocol/inspector uv --directory /path/to/spotify-mcp run spotify-mcp変更点 | 影響 | ステータス |
検索 | 1検索あたりの結果数が減少 | 対応済み |
プレイリストエンドポイント | エンドポイントURLが変更 | 対応済み |
レスポンスフィールド | 解析処理を更新 | 対応済み |
バッチGETエンドポイントの削除 | 個別に取得する必要あり | 対応済み |
トラックの | 利用不可 | 対応済み |
開発モード: 5ユーザー制限、Premium必須 | アクセス制限 | ドキュメント化済み |
オリジナルプロジェクト: varunneal/spotify-mcp by Varun Srivastava (MIT License)
オリジナル貢献者: @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj, @JJGO 他
保守に使用: Claude Code (Anthropic)
MIT License -- 詳細は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.
