Which integrations are available for this server?

Controls Spotify playback (play, pause, skip, volume), searches for tracks/albums/artists/playlists, fetches recommendations, and manages the queue via the Spotify Web API.

How do I use spotify-mcp-server?

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-server play some chill lo-fi music" 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-server

by hightechif

Overview Schema Related Servers Score Discussions

Python

Local

Spotify MCP Server

A Python-based Model Context Protocol (MCP) server that connects your AI assistant (Claude Desktop, Cursor, etc.) directly to the Spotify Web API. This allows the AI to inspect your current playback state, search for music, trigger recommendations, and control your player (play, pause, skip, adjust volume, queue tracks).

Built using Python 3.12+, the official FastMCP SDK, uv for dependency/project management, and fully type-annotated with strict mypy validation.

Features

🛠️ Exposed Tools

get_current_playback: Retrieves details about your active device, current volume, track name, artist, album, and progress.
pause_playback / resume_playback: Pauses or resumes playback.
skip_next / skip_previous: Skips to the next or previous track.
set_volume: Adjusts player volume (0 to 100).
add_to_queue: Appends a specific track URI to the queue.
search_spotify: Searches for tracks, albums, artists, or playlists.
play_by_search: Searches for an item and immediately starts playing the top result.
get_recommendations: Fetches track recommendations based on seed genres (e.g. lofi,chill).

📊 Exposed Resources

spotify://status: Exposes the text description of the currently playing track.

💬 Exposed Prompts

vibe_check: Guides the AI to curate and play a playlist matching your current coding task, energy level, and mood.

Related MCP server: Spotify MCP Server

Prerequisites

Spotify Premium: The Spotify Web API Player endpoints require a Spotify Premium subscription to accept control commands.
uv Package Manager: Install uv if you haven't already:
```
curl -LsSf https://astral.sh/uv/install.sh | sh
```

Setup & Installation

1. Register a Spotify Developer App

Go to the Spotify Developer Dashboard and log in.
Click Create App and fill in the details:
- App name: E.g. My Local MCP Server
- Redirect URI: http://127.0.0.1:8888/callback (Crucial for the authentication script to run successfully)
Under the app settings, copy your Client ID and Client Secret.

2. Configure Environment Secrets

Create a .env file in the root of this project:

cp .env.example .env

Open .env and fill in your client keys:

SPOTIFY_CLIENT_ID=your_client_id_here
SPOTIFY_CLIENT_SECRET=your_client_secret_here
SPOTIFY_REDIRECT_PORT=8888

3. Generate Spotify Refresh Token

Run the built-in OAuth helper script:

uv run get_token.py

This script spins up a temporary web server on 127.0.0.1:8888 and opens your default web browser to authorize the required permissions (user-read-playback-state, user-modify-playback-state, user-read-currently-playing).
After clicking "Agree", you will see a success message. Return to the terminal and copy the printed SPOTIFY_REFRESH_TOKEN to your .env file:

SPOTIFY_REFRESH_TOKEN=your_generated_refresh_token_here

Development & Type Checking

Ensure the codebase is type-safe and conforms to the static analysis rules:

uv run mypy .

MCP Client Configuration

To register this server with your AI client, add the following configuration block:

Claude Desktop

Add this to your claude_desktop_config.json (usually located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS).

Option A: Hiding Your Absolute Path (Recommended)

To keep your personal home directory paths private and avoid exposing them in configuration files, you can use an environment variable (e.g., SPOTIFY_MCP_DIR).

Export the variable in your shell profile (e.g., ~/.zshrc or ~/.bash_profile):
```
export SPOTIFY_MCP_DIR="/path/to/spotify-mcp-server"
```
Configure Claude Desktop to execute uv via a login shell, which resolves the environment variable dynamically:
```
{
  "mcpServers": {
    "spotify": {
      "command": "zsh",
      "args": [
        "-l",
        "-c",
        "uv --directory \"$SPOTIFY_MCP_DIR\" run main.py"
      ]
    }
  }
}
```
(If you are using bash, replace "command": "zsh" with "command": "bash" and load profile accordingly)

Option B: Standard Direct Configuration

If you do not mind exposing your directory path, configure the absolute path directly:

{
  "mcpServers": {
    "spotify": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/spotify-mcp-server",
        "run",
        "main.py"
      ]
    }
  }
}

(Note: Replace /path/to/spotify-mcp-server with the actual absolute path to this repository on your system)

Available Tools

8 tools

get_current_playbackC

Get information about the user's current Spotify playback state.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose authentication needs (access_token parameter), error conditions, or behavior when no playback is active.

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?

Single sentence with no wasted words, but critically under-specified. Could include parameter and usage hints without sacrificing conciseness.

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 simple tool with one parameter and no output schema, the description still leaves gaps: no parameter explanation, no return value description, no error handling context.

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

Parameters1/5

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

The description does not mention the access_token parameter at all. With 0% schema description coverage, the agent receives no parameter guidance.

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 a specific verb (Get) and resource (current Spotify playback state). It distinguishes itself from sibling tools like pause_playback and skip_next which are actions.

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 explicit guidance on when to use this tool vs alternatives. The description implies retrieving current state, but does not mention prerequisites or scenarios.

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

pause_playbackB

Pause the current audio playback on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states the action without disclosing behavioral traits such as whether it silently fails if no device is active, rate limits, or authentication requirements beyond the access_token parameter.

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 concise sentence with no unnecessary words. However, given the simplicity, it could include additional useful information without becoming verbose.

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?

With no output schema, no annotations, and only one parameter lacking description, the tool definition is incomplete. It does not address error handling, prerequisites (e.g., must have an active session), or expected return behavior.

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

Parameters1/5

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

The description does not mention the access_token parameter, and schema description coverage is 0%. Thus it adds no meaning beyond the parameter's existence 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 'Pause the current audio playback on Spotify' clearly states the verb 'Pause' and the specific resource 'current audio playback on Spotify', distinguishing it from sibling tools like resume_playback or skip_next.

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 when the user wants to stop active playback, but provides no explicit guidance on when not to use it, prerequisites, or comparisons to alternatives like resume_playback.

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

play_by_searchC

Play a track or playlist by searching for it first.

ParametersJSON Schema

Name	Required	Default
`type`	No	track
`query`	Yes
`access_token`	No

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description must carry behavioral disclosure. It only states it plays after searching, omitting what happens with multiple results, error behavior if no results, or impact on current playback. The destructive nature is implied but not detailed.

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

Conciseness2/5

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

Single sentence, but too brief; sacrifices necessary details for brevity. Not an example of efficient conciseness as it leaves significant gaps.

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

Completeness1/5

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

Given no output schema, no annotations, and minimal description, the tool definition is highly incomplete. An agent lacks information about response format, error handling, practical usage constraints (e.g., device requirement), and expected behavior.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to parameters. It mentions 'query' implicitly but doesn't explain defaults for 'type' or the optional 'access_token'. Agent gains no extra understanding beyond parameter names.

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 is to 'play' and the resource is 'track or playlist' via searching. It effectively distinguishes from sibling 'search_spotify' which only returns search results. However, it doesn't specify whether it plays the first result or presents choices.

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 versus alternatives like 'search_spotify' (which only searches) or other playback tools. No mention of prerequisites such as an active playback device.

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

resume_playbackC

Resume the current audio playback on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing what happens if no playback is paused, error conditions, or any side effects. The agent lacks 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 a single sentence with no fluff, but it is too concise and omits important details like parameter usage and behavior. It achieves conciseness at the cost of completeness.

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 low complexity, the description still lacks information about the optional parameter, error conditions, and prerequisites. It is not sufficient for an agent to reliably invoke the tool without additional knowledge.

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

Parameters1/5

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

Schema coverage is 0%, and the description does not mention the 'access_token' parameter at all. It adds no meaning beyond the schema, failing to compensate for the lack of parameter documentation.

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 verb 'resume' and the resource 'current audio playback'. It distinguishes from sibling tools like pause_playback and play_by_search by implying a specific action to continue paused 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?

The description implies the tool is used when playback is paused, but does not explicitly state when to use or not use it, or mention prerequisites like an active Spotify session. No alternatives or exclusions are provided.

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

search_spotifyC

Search Spotify's catalog for tracks or playlists.

ParametersJSON Schema

Name	Required	Default
`type`	No	track
`query`	Yes
`access_token`	No

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided, so the description must convey all behavioral traits. It only states it's a search operation, lacking details on authentication needs, rate limits, result format, or that it is read-only.

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 a single concise sentence, but it is too brief to be adequately informative. Conciseness is achieved at the cost of missing essential details.

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?

The tool has 3 parameters with no schema descriptions and no output schema. The description is too sparse to provide a complete picture, omitting how to use parameters and what the output is.

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?

With 0% schema description coverage, the description should explain parameters. It only hints at the 'type' parameter by mentioning tracks or playlists, but does not describe 'query' or 'access_token'.

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 searches Spotify's catalog for tracks or playlists, distinguishing it from sibling playback control tools. However, it doesn't mention that the 'type' parameter filters results, which is a minor omission.

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 vs. siblings or how it fits into a workflow. The description simply states what it does without context or alternatives.

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

set_volumeB

Set the playback volume percentage on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No
`volume_percent`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action without discussing side effects, failure conditions (e.g., invalid volume_percent out of range), or requirements (e.g., active device). This is insufficient for safe invocation.

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 of 8 words, efficient and front-loaded. It could be expanded slightly to include key behavioral notes without losing conciseness, but is not overly verbose.

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 has 2 parameters, no output schema, and no annotations, the description is too sparse. An agent lacks critical context such as valid volume range, need for active playback, or response behavior. This leads to potential misuse or failure.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no information about parameters beyond their names. The 'volume_percent' parameter is implied but no format, range, or semantics are clarified. The optional 'access_token' parameter is not mentioned at all.

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 verb 'Set', the resource 'playback volume percentage', and the platform 'Spotify'. It is distinct from sibling tools which handle playback control (pause, resume, skip) or search, leaving no ambiguity about the tool's function.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies a singular action, but does not mention prerequisites (e.g., active playback) or when not to use it. Sibling names provide some context, but the description itself lacks usage direction.

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

skip_nextB

Skip to the next track on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No

TDQS

B3.1/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. It gives no information about prerequisites (e.g., authentication via access_token), side effects, or error conditions. This limits the agent's understanding of tool behavior.

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 effectively communicates the core action. Every word earns its place.

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 simplicity and lack of output schema, the description is incomplete. It omits crucial context like authentication requirements and does not clarify the tool's behavior when no active playback exists.

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

Parameters1/5

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

The input schema has one parameter (access_token) with 0% description coverage, and the tool description does not explain its purpose or usage. The agent is left to infer from the parameter name alone.

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 action ('Skip to the next track on Spotify') with a specific verb and resource. It is distinguishable from sibling tools like 'skip_previous' and other playback controls.

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?

No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied from the name and action, but there is no contrast with alternatives beyond the sibling list.

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

skip_previousC

Skip to the previous track on Spotify.

ParametersJSON Schema

Name	Required	Description	Default
`access_token`	No

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description bears full burden. It does not disclose behavioral traits such as what happens if no previous track exists, whether it restarts the current track, or authentication requirements. This is insufficient for safe agent invocation.

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, well-structured sentence that is front-loaded. However, the extreme brevity sacrifices completeness, which is not the goal of conciseness alone.

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 simplicity (1 param, no output schema), the description provides only the core action. It omits crucial context about the access token, prerequisites (e.g., active playback), and error states, making it incomplete for reliable use.

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

Parameters1/5

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

The schema description coverage is 0%, and the description does not explain the 'access_token' parameter. The agent has no information about its purpose (likely authentication) or how to use it.

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 'skip to the previous track' on Spotify, effectively distinguishing it from sibling 'skip_next'. However, it is minimal and could be more specific about edge cases.

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 'resume_playback' or 'skip_next'. The user is left to infer context from the tool name alone.

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.

8 tool updatesv0.1.0Jul 7, 2026
- First observedget_current_playback
- First observedpause_playback
- First observedplay_by_search
- First observedresume_playback
- First observedsearch_spotify
- First observedset_volume
- First observedskip_next
- First observedskip_previous

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a specific action (playback control, search, volume) with no overlapping purposes; an agent can clearly distinguish them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., pause_playback, set_volume, skip_next), with clear and predictable naming.

Tool Count5/5

8 tools are well-scoped for controlling Spotify playback and searching; not too many or too few for the intended functionality.

Completeness4/5

Covers core playback and search operations well, but misses device management, shuffle/repeat, and queue features, which are minor gaps for a playback-focused server.

Maintenance

ActivityNo data

ResponsivenessSyncing

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

Spotify
io.github.akutishevsky
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Entertainment & Media App Automation
2
spotify D
com.jojapi
Spotify: Spotify Data API for Millions of songs & podcasts, artists, albums, playlists and more.
Entertainment & Media Search
371
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,723
mytesla.io
io.mytesla
Control your Tesla from your AI assistant - climate, charging, access, and security.
Home Automation & IoT Travel & Transportation
2

Related MCP Servers

Spotify MCP Server
Entertainment & Media App Automation
makesh-kumar
F
license
B
quality
D
maintenance
Enables AI assistants to control Spotify playback, search for music, manage playlists, and interact with your Spotify library through natural language commands.
Updated 5 months ago (2026-03-23 21:47 UTC)
19
-
Spotify MCP Server
Entertainment & Media App Automation
Yonsn76
F
license
A
quality
D
maintenance
Enables AI assistants to control Spotify playback, search for music, manage playlists, and access library information through the Spotify API. Requires Spotify Premium for playback control features.
Updated 9 months ago (2025-12-10 23:27 UTC)
4
-
Spotify MCP Node Server
Entertainment & Media App Automation
igorgarbuz
A
license
B
quality
D
maintenance
Enables AI assistants to control Spotify playback, manage playlists, search music, and access listening history. Requires Spotify Premium and uses secure OAuth 2.0 with PKCE authentication.
Updated a year ago (2025-06-18 16:58 UTC)
13
109
MIT
Spotify MCP Server
Entertainment & Media Audio Processing
raulpetruta
F
license
Not graded
quality
D
maintenance
Enables AI assistants to control Spotify playback, search music, manage playlists and library, and access user listening insights via the Spotify Web API.
Updated a year ago (2025-10-12 16:54 UTC)
-

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/hightechif/spotify-mcp-server'

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