This MCP server lets you build and edit Spotify playlists from natural-language descriptions, using the model as the music recommender.
Search Spotify for tracks and resolve them to URIs (search_tracks), with query filters like artist, year, genre, and album.
Read the user's actual listening history — top tracks or artists over various time ranges (get_my_taste).
List the user's playlists (list_my_playlists) and view a playlist's full contents with track URIs and positions (get_playlist).
Create new playlists, optionally private and with a description (create_playlist).
Add tracks to a playlist, appending or inserting at a position, with automatic batching past Spotify's 100-track limit (add_tracks).
Remove tracks from a playlist, removing every occurrence, with automatic batching (remove_tracks).
Auth and token refresh are handled for you after a one-time login flow.
Allows building and editing Spotify playlists from natural language descriptions, including searching tracks, understanding the user's listening taste, listing and reading playlists, and creating, adding to, or removing tracks from playlists.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@spotify-mcp Make a playlist of upbeat indie rock for running."
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.
An MCP server that lets MCP clients build and edit Spotify playlists from a description. "Moody 90s trip-hop for a rainy commute", "add three more like the last one", "drop anything over five minutes", etc. This is just a personal project intended for personal use, if you find it useful, that's a side effect, and you're welcome to use it.
Spotify deprecated /recommendations, /audio-features, /audio-analysis and related-artists
for every app created after 2024-11-27, they return 403 and have no replacement. So the model
itself is the recommendation engine. These seven tools give it the three things it can't do itself:
Tool | Purpose | |
Resolve |
| Turn "Massive Attack – Teardrop" into a track URI. Supports |
Ground |
| Your real top tracks/artists, so "music like I listen to" means something |
Read |
| Find a playlist by name; see what's in it before editing |
Write |
| Build and edit. Batched past Spotify's 100-track-per-request cap automatically |
There's a similar project named spotify-mcp-server by Marcel Marais that exposes many more functionalities. If you want to use this tool but find that the current list of exposed functions aren't enough for what you want to do, I'd recommend looking at his MCP server instead.
Related MCP server: spotify-mcp
At developer.spotify.com/dashboard → Create app.
Footgun 1 — the redirect URI. Spotify rejects
localhost. Register the IP literal, exactly:http://127.0.0.1:8888/callback
Footgun 2 — the allowlist. New apps are in development mode: capped at 5 users, and each one must be added under Settings → User Management by their Spotify account email — including your own. Miss this and every API call 403s despite a perfectly valid token. (Extended quota has been organizations-only since 2025-05-15 and requires 250k+ monthly actives, so 5 users is the practical ceiling.)
Copy the Client ID and Client secret.
npm install && npm run build
export SPOTIFY_CLIENT_ID=...
export SPOTIFY_CLIENT_SECRET=...
npm run loginnpm run login prints an authorization URL (and tries to open your browser), catches the callback
on 127.0.0.1:8888, and writes a refresh token to ~/.config/spotify-mcp/token.json with mode
0600. One time only — the server refreshes access tokens itself from then on.
Scopes requested: playlist-modify-public, playlist-modify-private, playlist-read-private,
playlist-read-collaborative, user-top-read. No playback scopes — this server doesn't control
playback.
claude mcp add spotify \
--env SPOTIFY_CLIENT_ID=... \
--env SPOTIFY_CLIENT_SECRET=... \
-- node /absolute/path/to/spotify-mcp/dist/index.jsOr in a client config file:
{
"mcpServers": {
"spotify": {
"command": "node",
"args": ["/absolute/path/to/spotify-mcp/dist/index.js"],
"env": {
"SPOTIFY_CLIENT_ID": "...",
"SPOTIFY_CLIENT_SECRET": "..."
}
}
}
}Then just ask: "Make me a 20-track playlist of moody 90s trip-hop for a rainy commute."
npm test # node:test, no framework — chunking, pagination, token refresh, error handling
npm run build
npx @modelcontextprotocol/inspector node dist/index.js # poke the tools by handSet SPOTIFY_MCP_TOKEN_FILE to override the token location.
Stack: @modelcontextprotocol/server v2 + zod. Everything else is a Node built-in — no express,
no axios, no dotenv, no Spotify client library.
Auth flow: authorization code with client secret, not PKCE. Spotify doesn't rotate refresh tokens on this flow, so there's no lose-the-write-lose-the-account failure mode. Everything stays on loopback.
The playlist endpoints moved. Separately from the 2024-11-27 cull, Spotify retired the
/tracks playlist surface in favour of /items. Unlike the cull these do have replacements,
and the server uses them. Everything below 403s on the left, works on the right:
GET/POST/DELETE /playlists/{id}/tracks → .../items;
POST /users/{id}/playlists → POST /me/playlists;
item.track on a playlist entry → item.item;
playlist.tracks.total in /me/playlists → playlist.items.total;
and the DELETE body key {"tracks": [...]} → {"items": [...]}. That last one isn't in
Spotify's changelog — it 403s as "Insufficient client scope", which sends you hunting for a
scope problem you don't have.
/me/playlists lies about being empty. It returns a valid, empty page roughly 40% of the
time on an account that demonstrably has playlists. An empty list is a silently wrong answer
rather than an error, so list_my_playlists retries up to four times before believing it.
Its items.total count also lags behind writes by a few seconds; the playlist itself is correct.
Playlist visibility is not settable. public is accepted at creation and on update, returns
200, and is then ignored — new playlists come back public regardless. Flip it in the Spotify
client. Nothing to fix here; the API just doesn't honour the field.
Not included: playback control, playlist rename/reorder, saved-library reads. Add when wanted.
Append tracks to a playlist (or insert at a position). Pass as many URIs as you like — they are batched automatically. Get URIs from search_tracks; do not invent them.
| Name | Required | Description | Default |
|---|---|---|---|
| uris | Yes | Spotify track URIs, e.g. spotify:track:4cOdK2wGLETKBW3PvgPWqT | |
| position | No | 0-based insert position. Omit to append to the end. | |
| playlist_id | Yes | Playlist ID (the part after /playlist/ in a Spotify URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal non-obvious behavior: many URIs are accepted and 'batched automatically,' and omitting position appends to the end. However, it does not mention permissions, duplicate handling, or response/error behavior.
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?
Three short sentences, front-loaded with the core purpose and no filler. Each sentence adds distinct information: action, batching, and input provenance.
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?
For a 3-parameter tool with no output schema, the description covers the main invocation concerns: required IDs, URI sourcing, and position semantics. It is slightly incomplete regarding post-conditions and error behavior, but the core call is fully specified.
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?
The schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds value by specifying URI provenance (search_tracks), automatic batching, and the append-vs-position distinction, pushing it above baseline.
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?
The description opens with a specific verb and resource: 'Append tracks to a playlist (or insert at a position).' This clearly states the action and distinguishes it from siblings like remove_tracks. The title and description align.
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?
It provides practical usage guidance by instructing the agent to 'Get URIs from search_tracks; do not invent them.' The append/insert semantics make the intended use case clear, though it does not explicitly state when to prefer this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty playlist, then fill it with add_tracks. Give it a name and a short description that reflects what the user asked for. Returns the playlist ID and its URL.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| public | No | Private by default | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the playlist is created empty and that the response returns the playlist ID and URL. It does not mention auth requirements or broader side effects, but the core mutation and return behavior are clearly stated.
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?
Three concise sentences with no redundancy: the first states the core action and workflow, the second provides parameter guidance, and the third states the return values. Each sentence earns its place.
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?
For a simple 3-parameter create tool with no output schema, the description covers the creation side effect, the empty playlist state, the response format, and the follow-up tool. It omits only details like privacy defaults, which are already in the schema.
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?
Schema coverage is low at 33%, so the description compensates by giving meaning to the required name parameter and the description parameter ('short description reflecting what the user asked for'). The public parameter is left to the schema, which already explains the default false behavior. This is a reasonable compensation.
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?
Description states a specific verb and resource: 'Create a new empty playlist'. It also explicitly distinguishes itself from add_tracks by signaling that this tool only creates the playlist and that tracks are added afterward. This clearly differentiates it from the sibling tools list.
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?
The description gives explicit workflow guidance: create the playlist first, then use add_tracks to fill it. It also instructs to name the playlist and write a short description reflecting the user request. It does not explicitly state when not to use alternatives, but the creation workflow is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's actual listening history — the best available signal for what they like. Read this before building a playlist described in terms of the user's own taste ("music like what I listen to", "more of this vibe"), then choose similar music yourself. Spotify's recommendation and audio-feature endpoints no longer exist for this app. Pick the music yourself from your own knowledge, then use search_tracks to resolve each pick to a URI. Use get_my_taste to ground picks in what this user actually listens to.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | tracks | |
| limit | No | ||
| time_range | No | short_term ≈ last 4 weeks, medium_term ≈ 6 months, long_term ≈ years | medium_term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It implies a read-only operation ('read this', 'listening history') and usefully discloses that recommendation/audio-feature endpoints are no longer available. However, it does not explicitly state the return shape, ranking/count behavior, or any auth/error considerations, leaving part of the behavioral contract implicit.
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?
The core purpose and workflow are front-loaded, and each sentence adds context: what the data is, when to read it, and how to use it with search_tracks. The final sentence partly repeats the earlier 'ground picks' instruction, making the description slightly longer than necessary, but it remains tight and readable.
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?
For a simple top-items getter with no output schema and no annotations, the description nicely covers when and how to use the tool in the playlist-building workflow. The main gap is that it never describes what the returned objects look like or whether they include URIs, which an agent would need to know for downstream steps.
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?
Only time_range is described in the schema (33% coverage). The description adds context around 'top tracks or artists' and the notion of listening history, which gives meaning to the type parameter, but it does not add detail about limit or how the ranking is determined. The schema's enums/defaults and time_range description do some of the work, so the description provides partial but not complete compensation.
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?
The description clearly names the resource ('the user's actual listening history') and the action (top tracks or artists), and differentiates it from sibling tools by positioning it as the personal-taste grounding source rather than catalog search or playlist management. The title reinforces the tracks-or-artists output, so an agent can distinguish it from search_tracks at a glance.
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?
It gives explicit when-to-use guidance: read this before building an own-taste playlist, then choose similar music, then resolve picks via search_tracks. It also explains an alternative that no longer exists (recommendation/audio-feature endpoints), preventing the agent from attempting unavailable calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full track listing of a playlist, with each track's URI and its 0-based position. Read this before editing so you know what is already there — it prevents duplicate adds and lets you remove exactly the right tracks.
| Name | Required | Description | Default |
|---|---|---|---|
| playlist_id | Yes | Playlist ID (the part after /playlist/ in a Spotify URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states what the operation returns and implies it is a non-mutating read operation through 'Read this before editing'. It does not explicitly say 'this does not modify the playlist' or mention pagination, but that is a minor gap for a simple getter.
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?
Two compact sentences. The first states what the tool returns, and the second explains when and why to use it. Every word contributes, and the most important information is front-loaded.
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?
For a single-parameter read-only tool with no output schema, the description is largely complete: it explains the return contents, the position semantics, and the practical workflow. It could add an explicit read-only statement or note about large playlists, but nothing critical is missing.
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?
The only parameter, playlist_id, is already 100% documented in the schema with a helpful description ('the part after /playlist/ in a Spotify URL'). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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?
The description uses a specific verb ('get') and resource ('playlist contents'), and specifies exactly what is returned: full track listing with URIs and 0-based positions. This clearly distinguishes it from siblings like search_tracks, list_my_playlists, and add_tracks.
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?
The description provides clear context for when to use the tool: 'Read this before editing'. It connects the tool to the add/remove workflow and explains the benefit (preventing duplicate adds, removing the right tracks). It does not explicitly name alternatives or exclusion conditions, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's playlists, with IDs. Use this to find an existing playlist to edit when the user names one ("add these to my Focus playlist") instead of creating a new one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavior itself. It conveys the scope (user's playlists), the output (IDs), and the intended read/lookup use case, but it does not explicitly state that the call is read-only or describe limitations such as pagination or an empty playlist list.
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?
Two sentences with no filler: the first states the result set and the second provides the decision rule. The usage guidance is front-loaded and easy for an agent to act on.
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?
For a parameterless list operation, the description covers the key facts: what is returned (playlists with IDs) and when to use it (find an existing playlist by user-supplied name). It stops short of documenting the full response shape or explicitly labeling the operation as read-only, but these are minor omissions given the tool's simplicity.
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?
The tool has no parameters, making schema coverage vacuously complete. There is no parameter information that the description could add, so the baseline of 4 applies.
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?
The description identifies the resource ('the user's playlists') and signals that IDs are part of the returned data. It also clarifies the tool's role as a lookup for an existing playlist to edit, distinguishing it from creating a new one, though it never uses an explicit verb like 'lists' or 'returns.'
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?
The description gives a concrete trigger: call this when the user names a playlist they want to edit, as in 'add these to my Focus playlist.' It also supplies a when-not by saying 'instead of creating a new one,' which routes the agent away from create_playlist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove every occurrence of the given tracks from a playlist. Batched automatically. Call get_playlist first to confirm the exact URIs present.
| Name | Required | Description | Default |
|---|---|---|---|
| uris | Yes | Spotify track URIs, e.g. spotify:track:4cOdK2wGLETKBW3PvgPWqT | |
| playlist_id | Yes | Playlist ID (the part after /playlist/ in a Spotify URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses duplicate removal ('every occurrence') and automatic batching, but does not warn about irreversibility, permissions, or behavior for invalid URIs.
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?
Two sentences with no filler: main action first, then batching behavior, then the prerequisite call. Every sentence contributes useful information.
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?
Covers the essential workflow, duplicate handling, and batching for a straightforward two-parameter tool. Lacks explicit destructive-operation warnings, but the core invocation information is present.
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?
Schema coverage is 100%, so parameters are already well documented. The description adds value by advising the agent to verify exact URIs via get_playlist, reinforcing correct use of the uris parameter.
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?
Description uses a specific verb and resource: remove tracks from a playlist, and explicitly notes it removes every occurrence. This clearly distinguishes it from add_tracks and other playlist-related siblings.
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?
Gives a concrete precondition: call get_playlist first to confirm exact URIs. It does not explicitly mention when not to use it or name add_tracks as the inverse alternative, but the intended workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tracks on Spotify and get their URIs. This is how you turn an artist/title you have in mind into something you can add to a playlist. Supports Spotify query syntax: artist:Portishead, year:1990-1999, genre:trip-hop, album:Dummy, and quoted phrases. Search one track at a time for precision. Spotify's recommendation and audio-feature endpoints no longer exist for this app. Pick the music yourself from your own knowledge, then use search_tracks to resolve each pick to a URI. Use get_my_taste to ground picks in what this user actually listens to.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search query, e.g. `artist:Massive Attack Teardrop` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavioral quirks: Spotify query syntax, the non-existence of related endpoints, and the intended usage pattern. It doesn't cover rate limiting or auth, but provides strong context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and each sentence adds value, though slightly verbose. The description efficiently packs syntax, alternatives, and constraints without redundancy.
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?
For a simple two-param tool with no output schema, it explains the return (URIs), query syntax, and how to combine with get_my_taste. It doesn't detail response structure or error cases, but those are less critical here.
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?
Schema covers one of two params (query) and description adds query syntax detail beyond the schema. The limit param is left undocumented in both schema and description, so while query semantics are enriched, the coverage gap holds the score at mid-level.
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?
States a specific action ('Find tracks on Spotify and get their URIs') with a clear resource and outcome. The description also explains the tool's role in the workflow, distinguishing it from playlist management siblings.
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?
Explicitly instructs when to use it ('turn an artist/title into a URI') and when not to: it disclaims recommendation and audio-feature endpoints no longer exist and directs the agent to use get_my_taste for grounding. It also advises searching one track at a time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_trackscreate_playlistget_my_tasteget_playlistlist_my_playlistsremove_trackssearch_tracksEach tool targets a clearly distinct action: searching tracks, reading listening history, listing playlists, reading a playlist's contents, creating playlists, adding tracks, and removing tracks. The descriptions further reinforce boundaries, so an agent should not confuse them.
All tool names follow a consistent verb_noun snake_case pattern: search_tracks, get_my_taste, list_my_playlists, get_playlist, create_playlist, add_tracks, remove_tracks. There are no mixed conventions or vague verbs.
Seven tools is well-scoped for a Spotify playlist-management server. Each tool covers a necessary step in the core workflow without redundancy or bloat.
The playlist workflow is well covered: discover via search/taste, list/read playlists, create playlists, and add/remove tracks. Minor gaps like renaming or deleting playlists are missing, but they are not central to the apparent purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, inspect, and manage Wubble music, speech, voice, and sound-effect requests through MCP.
Spotify MCP — Web API via client_credentials OAuth
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seenws/spotify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
