Spotify MCP Server
Сервер Spotify MCP
Простой сервер Model Context Protocol (MCP), который позволяет вам взаимодействовать со Spotify через Claude. Этот сервер позволяет Claude искать песни, создавать плейлисты, получать рекомендации и многое другое, используя ваш аккаунт Spotify.
Функции
Поиск треков на Spotify
Просмотр вашего профиля Spotify
Создавайте плейлисты
Добавить треки в плейлисты
Получайте персонализированные музыкальные рекомендации
Related MCP server: Spotify MCP Server
Доступные инструменты
Название инструмента | Описание |
| Установите учетные данные для аутентификации Spotify |
| Проверьте, верны ли ваши учетные данные и кто вошел в систему |
| Поиск треков по названию, исполнителю или ключевым словам |
| Получите информацию о своем профиле Spotify |
| Создайте новый плейлист в своей учетной записи |
| Добавить треки в существующий плейлист |
| Получайте рекомендации на основе семенных треков |
Инструкции по установке
1. Предпосылки
Node.js v16 или выше
нпм
Аккаунт Spotify
Зарегистрированное приложение Spotify Developer
2. Создайте приложение для разработчиков Spotify
Перейти к панели инструментов разработчика Spotify
Войдите в систему, используя свою учетную запись Spotify.
Нажмите «Создать приложение».
Введите название и описание приложения.
Добавьте
http://localhost:8888/callbackв качестве URI перенаправленияЗапишите свой идентификатор клиента и секретный код клиента.
3. Установить проект
# Clone or download the project first
cd spotify-mcp-server
# Install dependencies
npm install4. Получите токены Spotify
Отредактируйте файл spotify-auth.js , включив в него свой идентификатор клиента и секретный ключ клиента:
// 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Это позволит:
Откройте URL в вашем браузере.
Предложить вам войти в Spotify
Запросите разрешение на доступ к вашей учетной записи.
Сохраните токены в
secrets.json
5. Создайте сервер MCP
npm run build6. Настройте рабочий стол 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:
Посмотрите файл
secrets.json, чтобы получить свои учетные данные.Используйте инструмент
set-spotify-credentialsдля аутентификацииЗатем используйте любой другой инструмент 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Ошибки аутентификации : Ваши токены могли устареть. Запустите скрипт аутентификации еще раз, чтобы получить свежие токены
Неверные учетные данные : дважды проверьте, что вы используете правильный идентификатор клиента и секретный ключ клиента.
Примечания
Сервер хранит учетные данные только в памяти.
Вам нужно будет вводить учетные данные каждый раз, когда вы начинаете новый разговор.
Если Claude Desktop перезагрузится, вам придется снова задать учетные данные.
Available Tools
7 toolsadd-tracks-to-playlistD
| Name | Required | Description | Default |
|---|---|---|---|
| playlistId | Yes | The Spotify playlist ID | |
| trackUris | Yes | Array of Spotify track URIs to add |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Description of the playlist | |
| name | Yes | Name of the playlist |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return | |
| seedTracks | Yes | Spotify track IDs to use as seeds (max 5) |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| query | Yes | Search query for tracks |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| accessToken | Yes | The Spotify Access Token | |
| clientId | Yes | The Spotify Client ID | |
| clientSecret | Yes | The Spotify Client Secret | |
| refreshToken | Yes | The Spotify Refresh Token |
TDQS
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.
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.
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.
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.
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.
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.
7 tool updates
v1.0.0- First observed
add-tracks-to-playlist - First observed
check-credentials-status - First observed
create-playlist - First observed
get-current-user - First observed
get-recommendations - First observed
search-tracks - First observed
set-spotify-credentials
TDQS
Scored across 7 tools
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.
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.
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.
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
Related MCP Connectors
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
Spotify: Spotify Data API for Millions of songs & podcasts, artists, albums, playlists and more.
Generate full songs with vocals, instrumentals and sound effects from text. One server for Suno, Google Lyria, Mureka, MiniMax, ACE-Step, YuE and ElevenLabs. Your agent can quote the credit cost before generating, start a song, wait for it to finish and return download links. Sign in with OAuth; optional daily credit caps; retries never charge twice.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceConnects Claude with Spotify to control playback, search music, get track information, and manage the queue through conversation.1-
- FlicenseAqualityDmaintenanceConnects Claude with Spotify, allowing users to control playback, search for music, get track/artist information, and manage the queue via the Spotify API.51-
- AlicenseNot gradedqualityNot gradedmaintenanceConnects 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.-
- AlicenseNot gradedqualityDmaintenanceEnables Claude to control Spotify features including playback control, playlist management, search, and accessing user's listening history and preferences through the Spotify API.1ISC