Skip to main content
Glama
deenesjakoruzh
g2dgaming

Spotify MCP Server

by g2dgaming
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Spotify-MCP MCP-Server

MCP-Projekt zur Verbindung von Claude mit Spotify. Basierend auf der API von spotipy-dev .

Merkmale

  • Wiedergabe starten, pausieren und überspringen

  • Suche nach Titeln/Alben/Interpreten/Wiedergabelisten

  • Informationen zu einem Titel/Album/Künstler/einer Playlist erhalten

  • Verwalten der Spotify-Warteschlange

  • Verwalten, Erstellen und Aktualisieren von Wiedergabelisten

Related MCP server: Spotify MCP Server

Demo

Stellen Sie sicher, dass Sie den Ton einschalten

Konfiguration

Spotify-API-Schlüssel erhalten

Erstellen Sie ein Konto auf developer.spotify.com . Navigieren Sie zum Dashboard . Erstellen Sie eine App mit der Umleitungs-URI http://127.0.0.1:8080/callback . Sie können einen beliebigen Port wählen, müssen aber http und eine explizite Loopback-Adresse (IPv4 oder IPv6) verwenden.

Weitere Informationen/Fehlerbehebung finden Sie hier . Möglicherweise müssen Sie Ihre MCP-Umgebung (z. B. Claude Desktop) ein- oder zweimal neu starten, bevor es funktioniert.

Führen Sie dieses Projekt lokal aus

Dieses Projekt ist noch nicht für temporäre Umgebungen (z. B. uvx -Nutzung) eingerichtet. Führen Sie das Projekt lokal aus, indem Sie dieses Repo klonen.

git clone https://github.com/varunneal/spotify-mcp.git

Fügen Sie dieses Tool als MCP-Server hinzu.

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

Claude Desktop unter Windows: %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"
    }
  }

Fehlerbehebung

Bitte melden Sie uns, wenn Sie dieses MCP nicht zum Laufen bringen. Hier sind einige Tipps:

  1. Stellen Sie sicher, dass uv aktualisiert ist. Ich empfehle Version >=0.54 .

  2. Stellen Sie sicher, dass Claude über Ausführungsberechtigungen für das Projekt verfügt: chmod -R 755 .

  3. Stellen Sie sicher, dass Sie über Spotify Premium verfügen (erforderlich zum Ausführen der Entwickler-API).

Dieses MCP gibt Protokolle an std err aus (wie in der MCP-Spezifikation angegeben). Auf dem Mac sollte die Claude Desktop-App diese Protokolle an ~/Library/Logs/Claude ausgeben. Auf anderen Plattformen finden Sie die Protokolle hier .

Sie können den MCP Inspector über npm mit diesem Befehl starten:

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

Beim Start zeigt der Inspector eine URL an, auf die Sie in Ihrem Browser zugreifen können, um mit dem Debuggen zu beginnen.

ZU TUN

Leider wurden viele nützliche Funktionen der Spotify-API verworfen . Die meisten neuen Funktionen sind eher unwichtig oder dienen dem Projekt.

  • Tests.

  • Hinzufügen von API-Unterstützung zum Verwalten von Wiedergabelisten.

  • Hinzufügen von API-Unterstützung für paginierte Suchergebnisse/Wiedergabelisten/Alben.

PRs geschätzt! Vielen Dank an @jamiew, @davidpadbury, @manncodes, @hyuma7, @aanurraj und andere für ihre Beiträge.

Einsatz

(alles)

Erstellen und Veröffentlichen

So bereiten Sie das Paket für die Verteilung vor:

  1. Abhängigkeiten synchronisieren und Sperrdatei aktualisieren:

uv sync

  1. Erstellen Sie Paketverteilungen:

uv build

Dadurch werden Quell- und Wheel-Distributionen im Verzeichnis dist/ erstellt.

  1. Auf PyPI veröffentlichen:

uv publish

Hinweis: Sie müssen PyPI-Anmeldeinformationen über Umgebungsvariablen oder Befehlsflags festlegen:

  • Token: --token oder UV_PUBLISH_TOKEN

  • Oder Benutzername/Passwort: --username / UV_PUBLISH_USERNAME und --password / UV_PUBLISH_PASSWORD

Available Tools

5 tools
SpotifyGetInfoA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
item_uriYesURI 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
NameRequiredDescriptionDefault
actionYesAction to perform: 'get', 'start', 'pause' or 'skip'.
num_skipsNoNumber of tracks to skip for `skip` action.
spotify_uriNoSpotify uri of item to play for 'start' action. If omitted, resumes current playback.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: 'get', 'get_tracks', 'add_tracks', 'remove_tracks', 'change_details'.
descriptionNoNew description for the playlist.
nameNoNew name for the playlist.
playlist_idNoID of the playlist to manage.
track_idsNoList of track IDs to add/remove.

TDQS

C2.9/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. It lists actions but fails to describe critical behavioral traits: authentication requirements (e.g., user authorization), rate limits, whether changes are reversible, error conditions, or what the tool returns. For a multi-action tool with mutations (add_tracks, remove_tracks, change_details), this is a significant gap.

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 header followed by a bulleted list of actions. Each bullet is clear and specific. However, the first line 'Manage Spotify playlists.' is somewhat redundant with the tool name, and the description could be more front-loaded with critical behavioral information.

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 multi-action tool with mutations and no annotations or output schema, the description is incomplete. It lacks essential context: authentication needs, error handling, return formats, and differentiation from sibling tools. The 100% schema coverage helps with parameters, but overall guidance for an AI agent remains inadequate.

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 5 parameters thoroughly. The description adds minimal value beyond the schema by listing action types, but doesn't provide additional semantic context (e.g., format of playlist_id, source of track_ids, or constraints on name/description changes). 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.

Purpose4/5

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

The description clearly states the tool's purpose as 'Manage Spotify playlists' and enumerates five specific actions (get, get_tracks, add_tracks, remove_tracks, change_details), providing a comprehensive overview of functionality. However, it doesn't explicitly differentiate this playlist management tool from sibling tools like SpotifyGetInfo or SpotifySearch, which likely handle different Spotify resources.

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 the sibling tools (SpotifyGetInfo, SpotifyPlayback, SpotifyQueue, SpotifySearch). It lists actions but offers no context about prerequisites, appropriate scenarios, or exclusions. Users must infer usage from action names alone.

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
NameRequiredDescriptionDefault
actionYesAction to perform: 'add' or 'get'.
track_idNoTrack 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
NameRequiredDescriptionDefault
limitNoMaximum number of items to return
qtypeNoType of items to search for (track, album, artist, playlist, or comma-separated combination)track
queryYesquery term

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.

  1. 5 tool updatesv1.0.0
    • First observedSpotifyGetInfo
    • First observedSpotifyPlayback
    • First observedSpotifyPlaylist
    • First observedSpotifyQueue
    • First observedSpotifySearch
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: SpotifyGetInfo retrieves metadata, SpotifyPlayback handles real-time playback control, SpotifyPlaylist manages playlist content and details, SpotifyQueue manages the playback queue, and SpotifySearch performs searches. There is no overlap in functionality that would cause confusion.

Naming Consistency5/5

All tool names follow a consistent 'Spotify' prefix with a descriptive noun or verb-noun pattern (e.g., SpotifyGetInfo, SpotifyPlayback, SpotifyPlaylist, SpotifyQueue, SpotifySearch). This uniformity makes the tool set predictable and easy to navigate.

Tool Count5/5

With 5 tools, the server is well-scoped for managing Spotify interactions, covering key areas like playback, playlists, search, queue, and general info. Each tool earns its place without feeling bloated or insufficient for the domain.

Completeness4/5

The tool set provides comprehensive coverage for core Spotify operations, including CRUD for playlists, playback control, search, and queue management. A minor gap is the lack of user profile or library management tools (e.g., managing saved tracks or albums), but agents can still handle most common workflows effectively.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers