What can you do with this server?

This MCP server lets an AI agent control Spotify — playback, search, queue, library, and playlists via the Spotify Web API. * Playback Control: Get current track info, start/resume playback, pause, skip tracks (with optional number of skips), go to the previous track, seek to a specific position, and set playback volume. * Search: Find tracks, albums, artists, or playlists with configurable result type and limit. * Queue Management: View the current playback queue or add a specific track to the queue. * Item Details: Retrieve detailed information about a track, album, artist, or playlist by URI (artist info includes albums and top tracks; albums/playlists include their tracks). * Library Management: List liked/saved tracks, save tracks to, or remove tracks from the library. * Playlist Management: List playlists, create new playlists, add or remove tracks, and delete (unfollow) playlists.

Which integrations are available for this server?

Allows controlling Spotify playback (start, pause, skip), searching for tracks/albums/artists/playlists, retrieving detailed info about music entities, and managing the Spotify queue.

How do I use spotify-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spotify-mcp play my Discover Weekly playlist" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

spotify-mcp

by chienchuanw

Overview Schema Related Servers Score Discussions

Python

Local

spotify-mcp

An MCP (Model Context Protocol) server that lets an AI agent such as Claude control Spotify — playback, search, queue, library, and playlists — through the Spotify Web API. Built on spotipy.

Related MCP server: Spotify MCP Server

Overview

spotify-mcp exposes Spotify as a set of MCP tools so that an agent can start and control playback, search the catalog, manage the queue, curate your saved tracks, and build playlists on your behalf. It runs locally over stdio and talks to Spotify using your own developer credentials.

The server is organized into small, single-responsibility modules and authenticates lazily: it starts without contacting Spotify and only builds an authenticated client the first time a tool is actually called. A separate CLI command handles the one-time OAuth authorization, so the server itself never needs an interactive browser flow.

This is a personal, actively-maintained fork of varunneal/spotify-mcp.

Features

Playback control: start, pause, skip, previous, seek, and set volume
Search for tracks, albums, artists, and playlists
Get detailed info about a track, album, artist, or playlist
Manage the playback queue (add, get)
Manage your library: list, save, and remove liked tracks
Manage playlists: list, create, add/remove tracks, and delete
Lazy authentication with a dedicated spotify-mcp-auth CLI for first-time login

Available tools

The server exposes six domain-grouped tools. Most take an action argument.

Tool	Actions	Notes
`SpotifyPlayback`	`get`, `start`, `pause`, `skip`, `previous`, `seek`, `volume`	`start` plays a `spotify_uri` or resumes; `seek` needs `position_ms`; `volume` needs `volume_percent` (0–100). Requires an active device and Premium.
`SpotifyQueue`	`add`, `get`	`add` needs `track_id`.
`SpotifySearch`	—	`query` (required), `qtype` (track/album/artist/playlist or comma-separated), `limit`.
`SpotifyGetInfo`	—	`item_uri` (required). Artist resolves to albums + top tracks; album/playlist resolve to their tracks.
`SpotifyLibrary`	`get_liked`, `save`, `remove`	`save`/`remove` need `track_ids`.
`SpotifyPlaylist`	`list`, `create`, `add_tracks`, `remove_tracks`, `delete`	`create` needs `name`; track ops need `playlist_id` + `track_ids`; `delete` unfollows the playlist (Spotify has no hard delete).

Playback and queue actions target the active Spotify device and require Premium. Search, get-info, library, and playlist management work without an open device.

Demo

Make sure to turn on audio.

Getting started

Prerequisites

Python 3.12 or newer
uv (recommended >= 0.54)
A Spotify account. Spotify Premium is required for playback control (search, library, and playlist management work without Premium).
A Spotify developer application (see below)

Create a Spotify app

Sign in at developer.spotify.com/dashboard and create an app.
Set the redirect URI to http://127.0.0.1:8888. You may choose any port, but Spotify now requires the loopback IP 127.0.0.1 for HTTP redirects — localhost is rejected as insecure.
Under the app's API settings, enable Web API.
While the app is in Development Mode, add the Spotify account you will authorize with under User Management. Accounts that are not on this list are rejected during authorization with a server_error.
Copy the Client ID and Client Secret.

Install and register the server

Clone the repository:

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

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
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:8888"
  }
}

Configuration

The server reads three variables, from the MCP client env block above or from a .env file in the project root:

Variable	Required	Description
`SPOTIFY_CLIENT_ID`	yes	Client ID from your Spotify app
`SPOTIFY_CLIENT_SECRET`	yes	Client Secret from your Spotify app
`SPOTIFY_REDIRECT_URI`	yes	Must exactly match the redirect URI configured in the dashboard, e.g. `http://127.0.0.1:8888`

Example .env:

SPOTIFY_CLIENT_ID=your_client_id
SPOTIFY_CLIENT_SECRET=your_client_secret
SPOTIFY_REDIRECT_URI=http://127.0.0.1:8888

First-time authorization

Because the MCP server communicates over stdio, it cannot run the interactive OAuth flow itself. Authorize once with the bundled CLI, which opens your browser and captures the redirect on a local server:

uv --directory /path/to/spotify-mcp run spotify-mcp-auth

This caches an access/refresh token. The server then reads that cached token and refreshes it automatically. Re-run spotify-mcp-auth only if you revoke access or change scopes. If your account is not on the app's allowlist, the command prints guidance on how to fix it instead of a traceback.

Project structure

src/spotify_mcp/
  __init__.py   entry points: main() (server) and auth_main() (auth CLI)
  server.py     MCP wiring — list_tools / call_tool dispatch to the registry
  tools.py      tool schemas (Pydantic) + per-domain handlers + registry
  client.py     SpotifyClient facade over spotipy + the @validate decorator
  parsers.py    pure functions that narrow Spotify's verbose JSON
  auth.py       OAuth config, SCOPES, lazy get_client() factory, auth CLI
  errors.py     exception -> user-facing message formatting
tests/          pytest suite, mocks spotipy (no network, no credentials)
docs/           design spec, implementation plan, and session status files

Key design points:

Lazy auth — the Spotify client is built on first use via get_client(), never at import time, so the server starts without credentials and only touches Spotify when a tool is called.
@validate — decorates playback/queue methods to refresh the token if expired and inject a candidate device when none is active. Catalog, library, and playlist calls are intentionally undecorated because they need no device.
Layered boundaries — server knows nothing of Spotify, tools handlers know nothing of the MCP session, and client knows nothing of MCP types. Each layer is unit-testable in isolation.

Development

Install dependencies (including the dev group) and run the test suite:

uv sync
uv run pytest

The tests mock spotipy and never touch the real Spotify API, so no credentials are needed to run them.

You can also inspect the server interactively with the MCP Inspector:

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

Troubleshooting

Make sure uv is up to date (>= 0.54 recommended).
Ensure the client has execution permissions for the project: chmod -R 755 /path/to/spotify-mcp.
Playback control requires Spotify Premium and an active device — open Spotify (desktop app, phone app, or the web player at open.spotify.com) and start playing so a device is available.
redirect_uri: insecure during authorization means you are using localhost; switch both the dashboard and SPOTIFY_REDIRECT_URI to http://127.0.0.1:8888.
server_error / access_denied during authorization usually means your account is not on the app's User Management allowlist while the app is in Development Mode.
The server logs to stderr per the MCP spec. On macOS, the Claude desktop app writes these to ~/Library/Logs/Claude. See the MCP logging docs for other platforms.

Contributing

Contributions are welcome. Fork the repository, create a feature branch off dev, run the test suite (uv run pytest), and open a pull request against dev.

Deprecated Spotify recommendation endpoints are out of scope. Possible future work includes paginated search/playlist/album results and a deployment story for ephemeral (uvx) usage.

License

Released under the MIT License. This project is derived from the original spotify-mcp by Varun Srivastava, also MIT-licensed; the original copyright notice is retained in the LICENSE file.

Available Tools

6 tools

SpotifyGetInfoC

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

ParametersJSON Schema

Name	Required	Description	Default
`item_uri`	Yes	URI like 'spotify:track:...'. artist->albums+top tracks; album/playlist->tracks.

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided. The description does not disclose side effects, permissions, or error behavior. The schema description for item_uri hints at different behavior for artist vs. album/playlist, but the description itself adds no behavioral context.

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

Conciseness3/5

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

The description is very concise (one sentence) but lacks important details about output or usage. It is not overly verbose, but it sacrifices completeness for brevity.

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?

No output schema exists, yet the description does not elaborate on what 'detailed info' includes. The schema partially fills this gap for item_uri, but the description itself is insufficient for the tool's complexity.

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

Parameters2/5

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

The description adds little beyond the schema: 'Spotify item (track, album, artist, or playlist)'. The schema already describes item_uri as a URI and outlines type-specific behavior. The addition is minimal.

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 retrieves detailed info about a Spotify item and lists the item types (track, album, artist, playlist). It distinguishes from siblings like SpotifySearch (searching) and SpotifyLibrary (library management) by focusing on getting details by URI.

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 siblings. No mention of prerequisites like needing a valid URI or when to prefer other tools for different operations (e.g., SpotifySearch for finding items).

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

SpotifyLibraryB

Manage saved (liked) tracks. - get_liked: list saved tracks. - save / remove: add or remove track_ids from the library.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items for 'get_liked'.
`action`	Yes	'get_liked', 'save', or 'remove'.
`track_ids`	No	Track IDs for 'save'/'remove'.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like authentication, rate limits, or mutability. It only says 'manage' without detailing that save/remove are write operations. Minimal transparency.

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 short and front-loaded with the purpose. Every sentence adds value with zero waste.

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?

No output schema and incomplete behavioral context. Does not explain what get_liked returns or what save/remove return. Lacks completeness for a tool without annotations or output schema.

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 descriptions cover all parameters (100%) and are clear. The tool description adds no extra value beyond summarizing the schema, so baseline 3 is appropriate.

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 it manages saved (liked) tracks and lists the actions. It implicitly differentiates from sibling tools (playlist, search, etc.) but does not explicitly differentiate.

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?

The description lists available actions but provides no explicit guidance on when to use this tool versus alternatives like SpotifySearch or SpotifyPlaylist. Usage is inferred from context.

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

SpotifyPlaybackA

Manage playback: get current track, start/resume, pause, skip, previous, seek, set volume. - get: info about the current track. - start: play spotify_uri, or resume if omitted. - pause / skip / previous. - seek: jump to position_ms. - volume: set volume_percent (0-100).

ParametersJSON Schema

Name	Required	Description
`action`	Yes	One of: get, start, pause, skip, previous, seek, volume.
`num_skips`	No	Number of tracks to skip for 'skip'.
`position_ms`	No	Target position for 'seek', in ms.
`spotify_uri`	No	URI for 'start'. If omitted, resumes.
`volume_percent`	No	Volume 0-100 for 'volume'.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, but the description does not disclose side effects (e.g., pausing interrupts playback), prerequisites (e.g., active device), or error conditions. It only describes what each action does without deeper behavioral context.

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 concise with bullet points for actions, but it repeats the same information in the first paragraph and the schema's description field. It is mostly efficient but could be more streamlined.

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?

The description covers all actions and basic parameter usage, but lacks mention of prerequisites or error handling. For a tool with multiple actions and no output schema, it provides adequate but not deep completeness.

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 the tool description repeats parameter info (e.g., 'seek: jump to position_ms'). The description adds minimal extra meaning beyond the schema, 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 manages playback with specific actions (get, start, pause, skip, previous, seek, volume), distinguishing it from siblings like SpotifyGetInfo and SpotifyQueue. Each action is briefly explained.

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

Usage Guidelines4/5

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

The description provides context for when to use each action (e.g., 'start: play spotify_uri, or resume if omitted'). However, it does not explicitly state when not to use the tool or mention alternatives like SpotifyQueue for queue management.

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

SpotifyPlaylistA

Manage playlists. - list: the current user's playlists. - create: make a new playlist (name required). - add_tracks / remove_tracks: modify a playlist's items (playlist_id + track_ids required). - delete: remove a playlist from your library (playlist_id required). Spotify has no hard delete; this unfollows it, which removes owned playlists from your view.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name for 'create'.
`action`	Yes	'list', 'create', 'add_tracks', 'remove_tracks', or 'delete'.
`public`	No	Whether a created playlist is public.
`track_ids`	No	Track IDs for add/remove.
`description`	No	Description for 'create'.
`playlist_id`	No	Playlist ID for add/remove.

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It does clarify the delete nuance (unfollow vs hard delete). However, it omits details on authentication requirements, rate limits, or side effects of other actions (e.g., adding tracks may have ownership/duplicate implications).

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, using a bullet list to present actions. It is front-loaded with the overall purpose and each sentence earns its place. Zero waste.

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 the tool's complexity (6 parameters, multiple actions) and lack of output schema, the description covers the main operations but does not specify return values or error behavior. An AI agent might need more detail on what each action returns (e.g., list returns playlist objects) for proper invocation.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by relating parameters to specific actions (e.g., name required for create, track_ids for add/remove). This contextual grouping enhances understanding beyond the schema's per-parameter descriptions.

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 playlists and lists five specific actions (list, create, add_tracks, remove_tracks, delete) with brief explanations. This provides a specific verb-resource mapping and distinguishes the tool from siblings by its focus on playlist operations.

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

Usage Guidelines4/5

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

The description provides clear context for each action, including required parameters (e.g., name for create, playlist_id for delete). It notes that delete unfollows rather than permanently removes. However, it does not explicitly state when not to use this tool or compare with alternatives like SpotifySearch for finding tracks.

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 a track.

ParametersJSON Schema

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

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only mentions basic actions (get/add) without disclosing side effects, permissions, rate limits, or return behavior. This is minimal disclosure.

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 that immediately conveys the tool's purpose without any extraneous 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 no output schema and lacking annotations, the description should cover expected return for 'get', error cases, and any limits. It only states the actions, leaving significant behavioral gaps.

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%, and the schema already describes both parameters sufficiently (action as 'add' or 'get', track_id for add). The description adds no additional meaning beyond what is 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 the playback queue with two specific actions: get or add a track. This distinguishes it from sibling tools like SpotifyPlayback (playback control) and SpotifyPlaylist (playlist 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?

The description implies usage for getting queue or adding a track but does not provide explicit when to use vs. alternatives or any prerequisites. No guidance on exclusion conditions.

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

SpotifySearchC

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

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max number of items to return.
`qtype`	No	track, album, artist, playlist, or comma-separated.	track
`query`	Yes	query term

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'Search for...' but does not mention that the operation is read-only, what data is returned, pagination, or any side effects. This is insufficient for an agent to understand the tool's behavior.

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 a single sentence that directly states the purpose. It is as concise as possible, though it could benefit from front-loading the most critical information. Every word is used efficiently.

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 lack of output schema and annotations, the description is incomplete. It does not explain the return format, error scenarios, or authentication requirements, leaving an agent with insufficient context for reliable invocation.

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?

The input schema has full description coverage: each parameter is documented. The tool description adds no extra meaning beyond the schema. Thus the baseline of 3 applies.

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 action (search) and the resources (tracks, albums, artists, playlists) which distinguishes it from sibling tools like SpotifyGetInfo. However, it is very brief and does not elaborate on the scope or types of search, lacking the specificity of high-scoring examples.

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 on when to use this tool versus alternatives (e.g., when to use SpotifyPlaylist instead). There is no mention of prerequisites, exclusions, or context for use.

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. Dates show when Glama detected each change.

6 tool updatesv0.3.0Jul 5, 2026

ChangedSpotifyGetInfo2 fields changed

changedInput schema / description

Previous value: -"Get detailed information about a Spotify item (track, album, artist, or playlist)."New value: +"Get detailed info about a Spotify item (track, album, artist, or playlist)."

changedInput schema / properties / item_uri / description

Previous value: -"URI of the item to get information about. If 'playlist' or 'album', returns its tracks. If 'artist', returns albums and top tracks."New value: +"URI like 'spotify:track:...'. artist->albums+top tracks; album/playlist->tracks."

AddedSpotifyLibrary

ChangedSpotifyPlayback6 fields changed

changedInput schema / description

Previous value: -"Manages the current playback with the following actions:\n- get: Get information about user's current track.\n- start: Starts playing new item or resumes current playback if called with no uri.\n- pause: Pauses current playback.\n- skip: Skips current track."New value: +"Manage playback: get current track, start/resume, pause, skip, previous, seek, set volume.\n- get: info about the current track.\n- start: play spotify_uri, or resume if omitted.\n- pause / skip / previous.\n- seek: jump to position_ms.\n- volume: set volume_percent (0-100)."

changedInput schema / properties / action / description

Previous value: -"Action to perform: 'get', 'start', 'pause' or 'skip'."New value: +"One of: get, start, pause, skip, previous, seek, volume."

changedInput schema / properties / num_skips / description

Previous value: -"Number of tracks to skip for `skip` action."New value: +"Number of tracks to skip for 'skip'."

addedInput schema / properties / position_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Target position for 'seek', in ms.",
+  "title": "Position Ms"
+}

changedInput schema / properties / spotify_uri / description

Previous value: -"Spotify uri of item to play for 'start' action. If omitted, resumes current playback."New value: +"URI for 'start'. If omitted, resumes."

addedInput schema / properties / volume_percent

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Volume 0-100 for 'volume'.",
+  "title": "Volume Percent"
+}

AddedSpotifyPlaylist

ChangedSpotifyQueue3 fields changed

changedInput schema / description

Previous value: -"Manage the playback queue - get the queue or add tracks."New value: +"Manage the playback queue - get the queue or add a track."

changedInput schema / properties / action / description

Previous value: -"Action to perform: 'add' or 'get'."New value: +"'add' or 'get'."

changedInput schema / properties / track_id / description

Previous value: -"Track ID to add to queue (required for add action)"New value: +"Track ID to add (required for 'add')."

ChangedSpotifySearch2 fields changed

changedInput schema / properties / limit / description

Previous value: -"Maximum number of items to return"New value: +"Max number of items to return."

changedInput schema / properties / qtype / description

Previous value: -"Type of items to search for (track, album, artist, playlist, or comma-separated combination)"New value: +"track, album, artist, playlist, or comma-separated."

4 tool updatesv0.2.0Jul 4, 2026
- First observedSpotifyGetInfo
- First observedSpotifyPlayback
- First observedSpotifyQueue
- First observedSpotifySearch

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct area of Spotify: info retrieval, library management, playback, playlists, queue, and search. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent PascalCase pattern with the prefix 'Spotify' and a noun indicating the function (e.g., SpotifyGetInfo, SpotifyPlayback).

Tool Count5/5

With 6 tools, the server is well-scoped, covering the core Spotify operations without being too sparse or overloaded.

Completeness4/5

The tool set covers essential operations like search, get info, library, playlists, playback, and queue. Minor gaps such as editing playlist details or recommendations are missing, but core workflows are complete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
314
platform7nOAuth
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2
Fathom MCP ServerOAuth
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
WHOOP — MissingMCPOAuth
com.missingmcp
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Health & Wellness Fitness Tracking
24

Related MCP Servers

Spotify MCP Server
Entertainment & Media App Automation
jamiew
A
license
A
quality
C
maintenance
Connects Claude with Spotify, allowing users to control playback, search for content, get music information, and manage the Spotify queue.
Updated a month ago (2026-07-30 18:11 UTC)
16
9
MIT
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 a year ago (2025-04-02 09:27 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
hrishi0102
F
license
D
quality
D
maintenance
Enables Claude to interact with Spotify by searching songs, creating playlists, getting recommendations, and managing your music through your Spotify account.
Updated a year ago (2025-08-13 10:43 UTC)
7
3
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chienchuanw/spotify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

spotify-mcp

Table of Contents

Overview

Features

Available tools

Demo

Getting started

Prerequisites

Create a Spotify app

Install and register the server

Configuration

First-time authorization

Project structure

Development

Troubleshooting

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API