Spotify Model Context Protocol
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_playlistB | |
| get_track_urisA | |
| update_playlistB | |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: create_playlist makes new playlists, get_track_uris looks up song metadata, and update_playlist modifies existing playlists. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tools follow a consistent verb_noun pattern (create_playlist, get_track_uris, update_playlist) with clear, descriptive names. There are no deviations in style or convention across the set.
With only 3 tools, the set feels thin for a Spotify integration, lacking operations like searching for playlists, deleting playlists, or managing user profiles. While the tools cover basic playlist creation and updating, the scope is limited compared to typical music service APIs.
There are significant gaps in the tool surface for a Spotify domain. Missing are tools for reading or listing existing playlists, deleting playlists, searching for tracks or artists beyond URI lookup, and user-related operations. This incompleteness will likely cause agent failures when trying to perform common Spotify tasks.