Skip to main content
Glama
Spotify MCP Server

Spotify MCP Server

by hrishi0102

Spotify MCP サーバー

Claude を介して Spotify とやり取りできるシンプルな Model Context Protocol (MCP) サーバーです。このサーバーにより、Claude は Spotify アカウントを使って曲を検索したり、プレイリストを作成したり、おすすめの表示などを行うことができます。

特徴

  • Spotifyでトラックを検索する

  • Spotifyプロフィールを表示する

  • プレイリストを作成する

  • プレイリストにトラックを追加する

  • パーソナライズされた音楽のおすすめを受け取る

Related MCP server: Spotify MCP Server

利用可能なツール

ツール名

説明

set-spotify-credentials

Spotifyの認証情報を設定する

check-credentials-status

資格情報が有効かどうか、誰がログインしているかを確認します

search-tracks

名前、アーティスト、キーワードでトラックを検索

get-current-user

Spotifyプロフィール情報を取得する

create-playlist

アカウントに新しいプレイリストを作成する

add-tracks-to-playlist

既存のプレイリストにトラックを追加する

get-recommendations

シードトラックに基づいて推奨事項を取得する

セットアップ手順

1. 前提条件

  • Node.js v16以上

  • npm

  • Spotifyアカウント

  • 登録済みのSpotify開発者アプリケーション

2. Spotify開発者アプリを作成する

  1. Spotify開発者ダッシュボードへ

  2. Spotifyアカウントでログイン

  3. 「アプリを作成」をクリックします

  4. アプリ名と説明を入力してください

  5. リダイレクトURIとしてhttp://localhost:8888/callbackを追加します。

  6. クライアントIDとクライアントシークレットをメモしてください

3. プロジェクトをインストールする

# Clone or download the project first
cd spotify-mcp-server

# Install dependencies
npm install

4. Spotifyトークンを入手する

spotify-auth.jsファイルを編集して、クライアント ID とクライアント シークレットを追加します。

// Replace these with your Spotify app credentials
const CLIENT_ID = "your_client_id_here";
const CLIENT_SECRET = "your_client_secret_here";

次に、認証スクリプトを実行します。

node spotify-auth.js

これにより、次のようになります。

  1. ブラウザでURLを開く

  2. Spotifyにログインするように促す

  3. アカウントにアクセスする許可を求める

  4. トークンをsecrets.jsonに保存する

5. MCPサーバーを構築する

npm run build

6. Claudeデスクトップを設定する

Claude Desktop 構成ファイルを編集します。

  • macOSの場合: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows の場合: %APPDATA%\Claude\claude_desktop_config.json

次の構成を追加します。

{
  "mcpServers": {
    "spotify": {
      "command": "node",
      "args": ["/full/path/to/spotify-mcp-server/build/spotify-mcp-server.js"]
    }
  }
}

/full/path/to/spotify-mcp-serverプロジェクト ディレクトリへの実際のパスに置き換えます。

7. Claude Desktopを再起動します

新しい構成をロードするには、Claude Desktop を閉じて再度開きます。

使用法

クロードとの会話を始めるときは、まず Spotify の資格情報を設定する必要があります。

  1. secrets.jsonファイルを参照して資格情報を取得します

  2. set-spotify-credentialsツールを使用して認証する

  3. その後、他のSpotifyツールを使用します

プロンプトの例

資格情報の設定

I want to connect to my Spotify account. Here are my credentials from secrets.json:

Tool: set-spotify-credentials
Parameters:
{
  "clientId": "your_client_id",
  "clientSecret": "your_client_secret",
  "accessToken": "your_access_token",
  "refreshToken": "your_refresh_token"
}

基本コマンド

アカウントを確認してください:

Can you check who I'm logged in as on Spotify?

Tool: get-current-user
Parameters: {}

トラックを検索:

Search for songs by Weekend

Tool: search-tracks
Parameters:
{
  "query": "Taylor Swift",
  "limit": 5
}

プレイリストを作成します:

Create a new playlist called "My Pretty pretty girlfriend"

Tool: create-playlist
Parameters:
{
  "name": "My Pretty pretty girlfriend",
  "description": "For my girlfriend. Created with Claude and the Spotify MCP server"
}

複数ステップのタスク

曲のプレイリストを作成する:

I want to create a workout playlist with energetic songs. First, search for some high-energy songs. Then create a playlist called "Workout Mix" and add those songs to it.

お気に入りに基づいて推奨事項を取得する:

I like the song "Blinding Lights" by The Weeknd. Can you search for it, then find similar songs, and create a playlist with those recommendations?

トラブルシューティング

  • エラー: アクセストークンが利用できません: まずset-spotify-credentialsツールを使用して資格情報を設定する必要があります

  • 認証失敗: トークンの有効期限が切れている可能性があります。認証スクリプトを再度実行して、新しいトークンを取得してください。

  • 無効な認証情報: 正しいクライアントIDとクライアントシークレットを使用していることを確認してください

注記

  • サーバーは資格情報をメモリにのみ保存します

  • 新しい会話を始めるたびに認証情報を設定する必要があります

  • Claude Desktopが再起動した場合は、資格情報を再度設定する必要があります。

Available Tools

7 tools
add-tracks-to-playlistD
NameRequiredDescriptionDefault
playlistIdYesThe Spotify playlist ID
trackUrisYesArray of Spotify track URIs to add

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

check-credentials-statusD
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create-playlistD
NameRequiredDescriptionDefault
descriptionNoDescription of the playlist
nameYesName of the playlist

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-current-userD
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-recommendationsD
NameRequiredDescriptionDefault
limitNoNumber of recommendations to return
seedTracksYesSpotify track IDs to use as seeds (max 5)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-tracksD
NameRequiredDescriptionDefault
limitNoNumber of results to return
queryYesSearch query for tracks

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

set-spotify-credentialsD
NameRequiredDescriptionDefault
accessTokenYesThe Spotify Access Token
clientIdYesThe Spotify Client ID
clientSecretYesThe Spotify Client Secret
refreshTokenYesThe Spotify Refresh Token

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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. 7 tool updatesv1.0.0
    • First observedadd-tracks-to-playlist
    • First observedcheck-credentials-status
    • First observedcreate-playlist
    • First observedget-current-user
    • First observedget-recommendations
    • First observedsearch-tracks
    • First observedset-spotify-credentials

TDQS

D1.8/5.0

Scored across 7 tools

Disambiguation4/5

Most tools have distinct purposes targeting different Spotify resources like playlists, user info, recommendations, and tracks, but 'add-tracks-to-playlist' and 'create-playlist' could be confused if an agent needs to both create and populate a playlist in one operation. The lack of descriptions increases minor ambiguity.

Naming Consistency3/5

The naming uses a mix of verb-noun patterns (e.g., 'create-playlist', 'search-tracks') and more descriptive phrases (e.g., 'check-credentials-status', 'set-spotify-credentials'), with all tools using kebab-case. This is readable but lacks a strict, predictable convention across all tools.

Tool Count5/5

With 7 tools, this server is well-scoped for a Spotify integration, covering core functionalities like user management, playlist operations, search, and recommendations without being overwhelming or too sparse.

Completeness3/5

The toolset covers key Spotify operations like user info, search, recommendations, and playlist management, but lacks update or delete operations for playlists and tracks, and missing tools for managing playback or albums creates notable gaps in a full music streaming workflow.

Maintenance

ActivityInactive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    Not graded
    maintenance
    Connects Claude to Spotify for music discovery, playlist creation, and collection analysis through natural language. Enables searching songs, analyzing music diversity, creating playlists, and getting recommendations using Spotify's API.
    -