Skip to main content
Glama
carllapierre

SpotifyMCP

by carllapierre
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

SpotifyMCP MCP Server

This is a TypeScript-based MCP server for Spotify based on the Model Context Protocol.

Features

Tools

  • create_playlist - Create a new Spotify playlist.

    • Takes name, description, tracks, and public status as parameters.

    • Returns the URI of the created playlist.

Prompts

  • search_songs - Search for songs on Spotify.

    • Takes a search query and an optional limit for results.

Related MCP server: MCP Spotify Player

Development

Install dependencies:

npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Installation

To use with Claude Desktop, add the server config:

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "SpotifyMCP": {
      "command": "node",
      "args": [
        "/Users/your_username/Documents/SideProjects/MCPs/spotify-mcp/build/index.js"
      ],
      "env": {
        "SPOTIFY_CLIENT_ID": "your_client_id_here",
        "SPOTIFY_CLIENT_SECRET": "your_client_secret_here",
        "SPOTIFY_REFRESH_TOKEN": "your_refresh_token_here"
      }
    },
  }
}

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Setup Instructions

  1. Create a Spotify Developer Account
    Visit Spotify Developer and create an account.

  2. Create a New Application
    After logging in, create a new application to obtain your Client ID and Client Secret.

  3. Set Up Redirect URI
    In your Spotify application settings, configure the redirect URI to: 

    http://localhost:8888/callback

  4. Create a .env File
    In the root of your project, create a .env file and add the following environment variables:

    SPOTIFY_CLIENT_ID=your_client_id_here
SPOTIFY_CLIENT_SECRET=your_client_secret_here
SPOTIFY_REDIRECT_URI=http://localhost:8888/callback

  5. Get Your Spotify Token
    Run the following command to obtain your Spotify token:

    npx ts-node src/scripts/get-spotify-token.ts

  6. Login to Your Application
    Visit http://localhost:8888/login in your browser Copy the refresh token and set it in your environment variables: SPOTIFY_REFRESH_TOKEN=your_refresh_token_here

Available Tools

2 tools
create_playlistB

Create a new Spotify playlist and return the URI to ALWAYS present to the user as a hyperlink

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the playlist
descriptionNoDescription of the playlist
tracksYesArray of Spotify track URIs
publicNoWhether the playlist should be public

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 for disclosing behavior. It mentions returning a URI and instructs to present it as a hyperlink, but lacks details on side effects, required permissions, rate limits, or what happens if the playlist creation fails. The description is insufficient for a mutation tool.

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, front-loaded sentence that communicates the core action and key instruction concisely. It wastes no words, though it could potentially add more detail without becoming verbose.

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?

Considering the lack of annotations and output schema, and the presence of 4 parameters (2 required), the description is minimal. It explains the return value (URI) and user instruction, but omits details about parameter effects (e.g., public defaults) and potential errors. It is adequate but not fully complete.

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 100% description coverage for all 4 parameters, so the schema already documents each parameter. The description does not add additional meaning or context beyond the schema, resulting in a baseline score of 3.

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 'Create', the resource 'Spotify playlist', and the action 'return the URI'. It also provides an instruction to present the URI as a hyperlink, which is specific and useful. The purpose is distinct from the sibling tool 'search_songs'.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide conditions for when not to use it. However, the sibling tool 'search_songs' is clearly for searching, so usage is implied. No guidance on prerequisites or exclusions.

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

search_songsC

Search for songs on Spotify

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (song name, artist, etc.)
limitNoMaximum number of results (1-50)

TDQS

C2.8/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 convey behavior. It only states it searches, implying a read operation, but fails to disclose any details about authentication, rate limits, result limits, or what happens with empty queries.

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, making it concise and front-loaded. However, it may be too brief, lacking important context that could be added without losing 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?

With no output schema and minimal description, essential context about return format, pagination, or usage limits is absent. The description is incomplete for a search tool that likely returns multiple results.

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%, so the description does not need to add param details. The description adds no additional meaning beyond the schema, but since the schema is clear, this is adequate.

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 'Search for songs on Spotify' clearly identifies the verb (search) and resource (songs on Spotify). While it does not explicitly differentiate from siblings, 'create_playlist' is a distinct action, so no confusion arises.

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 or any prerequisites. For instance, it does not mention that this tool is for searching existing content, unlike 'create_playlist' which creates new content.

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.

  1. 2 tool updatesv0.2.0
    • First observedcreate_playlist
    • First observedsearch_songs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one creates playlists, the other searches for songs. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (create_playlist, search_songs) with clear and predictable structure.

Tool Count3/5

With only 2 tools, the surface is too thin for a comprehensive music service like Spotify. This falls in the borderline range for tool count.

Completeness2/5

The set lacks many essential operations such as playing music, managing playlists (get, update, delete), and user library actions, leaving significant gaps.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • TIDAL Music MCP

    raydollete
    A
    license
    A
    quality
    C
    maintenance
    Enables searching, managing playlists, getting recommendations, and downloading music from TIDAL through natural language commands via the Model Context Protocol.
    16
    MIT

  • mcp-spotify

    RomitDeokar
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables searching and managing Spotify music, playlists, artists, albums, and audiobooks through natural language.
    35
    MIT

Latest Blog Posts

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

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