en es ja ko zh

Spotify MCP Server

Name: Spotify MCP Server
Author: varunneal

by varunneal

Overview Schema Source Related Servers Discussions Admin

Python

Local

spotify-mcp MCP 서버

Claude와 Spotify를 연결하는 MCP 프로젝트입니다. spotipy-dev의 API를 기반으로 구축되었습니다.

특징

재생 시작, 일시 정지 및 건너뛰기
트랙/앨범/아티스트/재생목록 검색
트랙/앨범/아티스트/재생목록에 대한 정보 얻기
Spotify 대기열 관리
재생목록 관리, 생성 및 업데이트

Related MCP server: Vulpes Spotify MCP Server

데모

오디오를 켜두세요

구성

Spotify API 키 받기

developer.spotify.com 에서 계정을 만드세요. 대시 보드 로 이동하세요. 리디렉션 URI를 http://127.0.0.1:8080/callback 으로 설정하여 앱을 만드세요. 원하는 포트를 선택할 수 있지만 http와 명시적인 루프백 주소(IPv4 또는 IPv6)를 사용해야 합니다.

자세한 정보/문제 해결 방법은 여기를 참조하세요. MCP 환경(예: Claude Desktop)을 한두 번 다시 시작해야 제대로 작동할 수 있습니다.

이 프로젝트를 로컬로 실행하세요

이 프로젝트는 아직 임시 환경(예: uvx 사용)에 맞게 설정되지 않았습니다. 이 저장소를 복제하여 로컬에서 프로젝트를 실행하세요.

지엑스피1

이 도구를 mcp 서버로 추가합니다.

MacOS의 Claude Desktop: ~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows의 Claude Desktop: %APPDATA%/Claude/claude_desktop_config.json

"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"
    }
  }

문제 해결

이 MCP가 작동하지 않으면 문제를 제기해 주세요. 몇 가지 팁을 알려드리겠습니다.

uv 최신 상태인지 확인하세요. >=0.54 버전을 권장합니다.
클로드에게 프로젝트에 대한 실행 권한이 있는지 확인하세요: chmod -R 755 .
Spotify 프리미엄이 있는지 확인하세요(개발자 API를 실행하는 데 필요).

이 MCP는 MCP 사양에 명시된 대로 std err에 로그를 출력합니다. Mac에서는 Claude Desktop 앱이 이 로그를 ~/Library/Logs/Claude 에 출력해야 합니다. 다른 플랫폼에서는 여기에서 로그를 확인할 수 있습니다 .

다음 명령을 사용하여 npm 통해 MCP Inspector를 시작할 수 있습니다.

npx @modelcontextprotocol/inspector uv --directory /path/to/spotify_mcp run spotify-mcp

Inspector를 실행하면 브라우저에서 접근하여 디버깅을 시작할 수 있는 URL이 표시됩니다.

할 일

안타깝게도 Spotify API에서 여러 가지 멋진 기능이 지원 중단되었습니다 . 대부분의 새로운 기능은 비교적 사소하거나 프로젝트 운영에 도움이 될 것입니다.

테스트.
재생목록 관리를 위한 API 지원 추가.
페이지별 검색 결과/재생 목록/앨범에 대한 API 지원 추가.

PR 감사합니다! @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj 등의 기여에 감사드립니다.

전개

(할 일)

건축 및 출판

배포를 위해 패키지를 준비하려면:

종속성 동기화 및 잠금 파일 업데이트:

uv sync

패키지 배포 빌드:

uv build

이렇게 하면 dist/ 디렉토리에 소스와 휠 배포판이 생성됩니다.

PyPI에 게시:

uv publish

참고: 환경 변수나 명령 플래그를 통해 PyPI 자격 증명을 설정해야 합니다.

토큰: --token 또는 UV_PUBLISH_TOKEN
또는 사용자 이름/비밀번호: --username / UV_PUBLISH_USERNAME 및 --password / UV_PUBLISH_PASSWORD

Available Tools

5 tools

SpotifyGetInfoA

Get detailed information about a Spotify item (track, album, artist, or playlist).

ParametersJSON Schema

Name	Required	Description	Default
`item_uri`	Yes	URI of the item to get information about. If 'playlist' or 'album', returns its tracks. If 'artist', returns albums and top tracks.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It explains return differences by type (tracks for albums/playlists, albums/top tracks for artists), but does not specify nondestructive nature, authentication needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It efficiently conveys the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description partially compensates by specifying behavior per item type, but it does not enumerate all returned fields (e.g., metadata like name, duration). This leaves some ambiguity for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and already details the URI parameter's behavior. The description adds no additional meaning beyond restating the tool's purpose, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information for a Spotify item (track, album, artist, or playlist), differentiating it from siblings like SpotifySearch (which searches by query) and SpotifyPlayback/Queue (which control playback).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the schema requiring a URI, but the description does not explicitly state when to use this tool over siblings or provide exclusions. An agent must infer context from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

SpotifyPlaybackB

Manages the current playback with the following actions: - get: Get information about user's current track. - start: Starts playing new item or resumes current playback if called with no uri. - pause: Pauses current playback. - skip: Skips current track.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'get', 'start', 'pause' or 'skip'.
`spotify_uri`	No	Spotify uri of item to play for 'start' action. If omitted, resumes current playback.
`num_skips`	No	Number of tracks to skip for `skip` action.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses basic behaviors like 'resumes current playback' for start and 'skips current track' for skip, but omits details on permissions, rate limits, error states (e.g., no active device), and whether get returns current track info or just status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one introductory sentence followed by a bullet list of actions. Every piece of information is front-loaded and relevant. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multi-action playback control) and lack of output schema or annotations, the description is incomplete. It fails to mention prerequisites like an active Spotify device, account type requirements, or error handling. Important operational context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The tool description does not add significant meaning beyond the schema's parameter descriptions; it repeats the same action list. For example, 'num_skips' and 'spotify_uri' are already explained in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages current playback and lists four specific actions (get, start, pause, skip). This is a specific verb+resource with clear action breakdown, distinguishing it from sibling tools like SpotifyGetInfo (which likely retrieves broader info) and SpotifyQueue (queue management).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor does it mention prerequisites (e.g., active device) or when not to use it (e.g., if user lacks Premium). Usage context is entirely implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

SpotifyPlaylistC

Manage Spotify playlists. - get: Get a list of user's playlists. - get_tracks: Get tracks in a specific playlist. - add_tracks: Add tracks to a specific playlist. - remove_tracks: Remove tracks from a specific playlist. - change_details: Change details of a specific playlist. - create: Create a new playlist.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'get', 'get_tracks', 'add_tracks', 'remove_tracks', 'change_details', 'create'.
`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 (required for create and change_details).
`description`	No	Description for the playlist.
`public`	No	Whether the playlist should be public (for create action).

TDQS

C2.6/5.0

Behavior2/5

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. While it lists six actions and their basic purposes, it doesn't disclose critical behavioral traits: authentication requirements, rate limits, whether operations are destructive, what happens on errors, or what the return values look like. For a multi-action tool with potential write operations (add, remove, change, create), 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a brief overview followed by a bulleted list of actions. Each bullet is concise and to the point. However, the opening 'Manage Spotify playlists' is redundant with the tool name and could be eliminated, and the bullet format while clear isn't the most natural language for AI comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-action tool with six parameters and no annotations or output schema, the description is incomplete. It doesn't explain return values, error conditions, authentication requirements, or the relationships between actions. The tool handles both read and write operations, but the description provides minimal behavioral context, making it inadequate for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it simply lists action names without explaining parameter dependencies or constraints. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Manage Spotify playlists' which is a vague purpose that doesn't specify what management entails. It then lists six sub-actions with brief explanations, but the overall purpose remains broad. While it distinguishes from sibling tools by focusing on playlists rather than search, playback, or queue operations, the verb 'manage' is too generic for clear understanding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus the sibling tools (SpotifyGetInfo, SpotifyPlayback, SpotifyQueue, SpotifySearch). The description lists six actions but doesn't explain when each should be used relative to each other or to other tools. There's no mention of prerequisites, authentication requirements, or contextual factors that would guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

SpotifyQueueB

Manage the playback queue - get the queue or add tracks.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action to perform: 'add' or 'get'.
`track_id`	No	Track ID to add to queue (required for add action)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description bears full responsibility. It fails to disclose behavior such as whether adding a track requires an active device, if the queue is appended or overwritten, or what errors occur. Minimal behavioral detail beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, concise sentence that immediately communicates the tool's purpose. No superfluous words, front-loads the resource and actions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and two actions, the description adequately covers purpose. It lacks details on return values or error cases but is sufficient for basic usage given no output schema and limited complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds marginal value by linking 'add tracks' to the action parameter and implying track_id for add. Baseline score is appropriate as schema handles semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages the playback queue with two specific actions: get or add tracks. It distinguishes itself from sibling tools like SpotifyPlayback by focusing on queue management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like SpotifyPlayback for control operations. The description simply lists actions without context on prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

SpotifySearchB

Search for tracks, albums, artists, or playlists on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	query term
`qtype`	No	Type of items to search for (track, album, artist, playlist, or comma-separated combination)	track
`limit`	No	Maximum number of items to return

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It mentions search types and parameters but omits behavior like response structure, pagination, error handling, auth needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single clear sentence, front-loaded with action verb. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is too brief. Lacks guidance on output format, pagination, or effective usage compared to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with descriptions for all 3 parameters. Description adds minimal context beyond schema (e.g., hinting at qtype values already documented). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it searches for tracks, albums, artists, or playlists on Spotify. Distinct from sibling tools like SpotifyGetInfo (specific item info), SpotifyPlayback (playback control), SpotifyQueue (queue management).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for searching Spotify content, but no explicit when-to-use vs alternatives, no when-not or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Jan 2, 2026
- First observedSpotifyGetInfo
- First observedSpotifyPlayback
- First observedSpotifyPlaylist
- First observedSpotifyQueue
- First observedSpotifySearch

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 11:30 across 5 tools

Disambiguation4/5

Most tools have distinct purposes: GetInfo for metadata, Playback for player control, Playlist for playlist management, Queue for queue operations, and Search for finding content. However, there is some potential overlap between GetInfo and Search, as both can retrieve item details, though GetInfo is more specific to known items while Search is for discovery.

Naming Consistency4/5

Tool names follow a consistent 'Spotify' prefix and descriptive noun-based naming (e.g., SpotifyPlayback, SpotifyPlaylist). The internal actions within tools (like get, start, pause) are also consistent. A minor deviation is that some tools use underscores in action names (e.g., get_tracks), while others do not, but overall the pattern is clear and readable.

Tool Count5/5

With 5 tools, the server is well-scoped for Spotify integration, covering key areas like playback control, playlist management, search, and queue handling. Each tool serves a distinct purpose without being overly broad or too narrow, making it manageable and functional for typical agent tasks.

Completeness4/5

The tool set covers core Spotify functionalities: playback control, playlist CRUD operations, search, and queue management. Minor gaps include lack of user profile management (e.g., get user info) or more advanced features like recommendations, but the essential workflows for playing music and managing content are well-supported.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
2145
Lacuna Music A
io.github.JOYLINK-LTD
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
AI & Machine Learning Audio Processing
315
LeadFoxConnectOAuth
io.github.LeadFox-Shay
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Marketing CRM
2
WHOOP — MissingMCPOAuth
com.missingmcp
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Health & Wellness Fitness Tracking
213

Related MCP Servers

Spotify MCP Server
Entertainment & Media App Automation
Naunau75
F
license
Not graded
quality
D
maintenance
Connects Claude with Spotify to control playback, search music, get track information, and manage the queue through conversation.
Updated 2 years ago (2025-04-02 09:27 UTC)
1
-
Vulpes Spotify MCP Server
Entertainment & Media Agent Orchestration
ejfox
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants like Claude to interact with Spotify, allowing them to search for tracks, control playback, and manage playlists.
Updated a year ago (2025-05-29 02:07 UTC)
1
-
Spotify MCP Server
Entertainment & Media API Testing
g2dgaming
F
license
A
quality
D
maintenance
Connects Claude with Spotify, allowing users to control playback, search for music, get track/artist information, and manage the queue via the Spotify API.
Updated a year ago (2025-06-02 17:27 UTC)
5
1
-
Spotify MCP Server
Entertainment & Media App Automation Content Management Systems
latiftplgu
F
license
A
quality
D
maintenance
A Model Context Protocol server that enables AI assistants like Claude Desktop to interact with Spotify's music streaming service, supporting playback control, playlist management, music search, and user profile access.
Updated a year ago (2025-07-30 16:45 UTC)
41
2
-

spotify-mcp MCP 서버

특징

데모

구성

Spotify API 키 받기

이 프로젝트를 로컬로 실행하세요

문제 해결

할 일

전개

건축 및 출판

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches