MCP Spotify Server

by JKGzenna

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, from search and playback control to playlist management and auth. There is no functional overlap that would cause an agent to choose the wrong tool for a given intent.
Naming Consistency5/5
All tools follow a consistent camelCase verb-noun pattern (e.g., searchSpotify, getNowPlaying, createPlaylist, addTracksToPlaylist). Even the auth tools fit the pattern, making the set predictable and easy to navigate.
Tool Count5/5
With 15 tools, the server is well-scoped for a Spotify integration covering search, playback, playlists, and authentication. Every tool has a clear purpose, and the count remains within the ideal range without unnecessary redundancy.
Completeness3/5
The server covers core workflows like searching, playing, pausing, and managing playlists, but notable gaps exist such as removing tracks from a playlist, deleting playlists, or controlling volume. These missing operations will require agents to work around limitations for full lifecycle management.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The text merely paraphrases the tool name without revealing side effects, authentication requirements, or post-conditions (e.g., whether tracks are appended or replaced). It does not add value beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant text. It is front-loaded with the core action, making it efficient and easy to parse for an AI agent.
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?
This is a mutation tool with no annotations, no output schema, and a minimal description. It fails to communicate important contextual details such as whether the operation is idempotent, duplicate handling, limits on track count, or required permissions. The description is under-specified for reliable tool selection and invocation.
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 description coverage is 100%, with each parameter (playlistId, trackIds, position) having a clear description. The tool description adds nothing extra about parameter usage, but the schema already provides sufficient meaning, so the baseline of 3 applies.
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 tool's action ('Add tracks') and resource ('a Spotify playlist'), using a specific verb+resource structure. It is distinct from sibling tools like addToQueue or createPlaylist, which target different operations.
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?
No guidance is provided on when to use this tool versus alternatives such as addToQueue or createPlaylist. The description lacks any context about prerequisites, sequencing, or preferred scenarios, offering zero actionable usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only says 'create' without explaining side effects (e.g., the playlist is added to the user's library), authentication needs, rate limits, or return value. This is minimal transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Create a new playlist on Spotify'. It is concise and contains no filler or redundant details, earning a maximum score.
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?
The tool is simple and the parameter schema is fully described, but the description lacks usage guidelines and behavioral context, and there is no output schema to indicate return values. It is minimally adequate for selection but has clear gaps regarding side effects and invocation expectations.
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 provides full descriptions for all three parameters (name, public, description), achieving 100% schema description coverage. The description adds no additional parameter meaning, but the schema fully compensates, so a baseline of 3 is appropriate.
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 'Create a new playlist on Spotify' uses the specific verb 'Create' and names the resource 'playlist' and platform 'Spotify', clearly distinguishing it from sibling tools like searchSpotify or addTracksToPlaylist. It unambiguously identifies the tool's core action.
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. It does not mention prerequisites like authentication, nor does it contrast with related tools such as addTracksToPlaylist or getMyPlaylists. There is no when/when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior (despite the limit parameter), whether all tracks are returned by default, or any authentication requirements. The description is purely declarative and lacks contextual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the tool's purpose. It is front-loaded with the action and resource, and there is no unnecessary verbiage or repetition.
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?
For a simple read tool with two parameters, the description is adequate but not complete. It lacks information about the return format (e.g., whether it returns track metadata, artists, or just IDs) and does not mention any constraints like default limit or pagination. Since there is no output schema, the description should have provided more context, but the schema covers parameter semantics.
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 already provides complete descriptions for both parameters (playlistId as the Spotify ID, limit with range 1-50). The description adds no additional meaning beyond what the schema offers, so the baseline of 3 is appropriate given 100% schema coverage.
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 'Get a list of tracks in a Spotify playlist' uses a specific verb ('Get') and identifies the exact resource ('tracks in a playlist'), clearly distinguishing it from sibling tools like getMyPlaylists or getRecentlyPlayed. It unambiguously states the tool's function.
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?
No guidance is provided on when to use this tool versus alternatives, such as searchSpotify or getMyPlaylists. There is no mention of exclusions or specific scenarios, leaving the agent to infer usage purely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose side effects, requirements (like active device), and behavior such as replacing current queue. It only states the action, leaving the agent to guess about deviceId handling, error conditions, or return values.
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?
A single, to-the-point sentence. It's efficient but lacks additional context that could aid selection; still, it doesn't waste words.
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 no annotations, the description fails to convey essential behavioral details such as whether playback starts immediately, what happens without a deviceId, or the response format. Incomplete for a 4-param tool with optional interactions.
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?
All four parameters are fully described in the schema, so the description adds no additional parameter semantics. It doesn't explain how id, uri, and type interrelate or which takes precedence.
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 uses a specific verb ('Start playing') and resource ('Spotify track, album, artist, or playlist'), clearly distinguishing from sibling playback controls like pause and skip. It accurately reflects the tool's function.
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?
No explicit when-to-use or alternative guidance is provided. While the function is intuitive, it doesn't mention exclusions (e.g., when to use resume vs play) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does not mention failure conditions (e.g., no active device, nothing paused), side effects, or whether it requires an active device to be set. The description only states the action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It efficiently conveys the core action and target, earning a perfect score for conciseness.
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?
For a simple one-parameter tool, the description covers the basic action and default behavior ('active device'). However, it lacks guidance on usage vs siblings and any note about error conditions, making it minimally complete but not comprehensive.
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 schema provides a full description for the single optional deviceId parameter ('The Spotify device ID to resume playback on'), achieving 100% coverage. The description adds no extra meaning beyond this, so a baseline score of 3 is appropriate.
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 states the specific verb 'Resume' and resource 'Spotify playback' with the scope 'on the active device'. This clearly distinguishes it from sibling tools like playMusic (which starts playback) and pausePlayback (the opposite action).
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?
No guidance is provided on when to use this tool versus alternatives such as playMusic or pausePlayback. The mention of 'active device' implies a prerequisite but does not explain when resumption is appropriate or what to do if no playback is paused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the tool name without adding behavioral context such as authentication needs, what 'recently played' means, or return format. It offers no insight beyond the literal operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no extraneous information, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description conveys the core purpose adequately. It lacks mention of authentication but is otherwise sufficient for this simple context.
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 schema fully documents the 'limit' parameter with description and range, and the tool description does not need to add parameter details. Schema coverage is 100%, so a baseline of 3 is appropriate.
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 action ('Get') and the resource ('recently played tracks on Spotify'), which distinctly identifies this from sibling tools like getNowPlaying and getMyPlaylists.
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?
No guidance is provided on when to use this tool vs alternatives such as getNowPlaying or searchSpotify. There is also no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details beyond the basic search action. It does not disclose authentication needs, pagination, default limits, error handling, or return format, leaving the agent to infer these from the schema or context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key verb 'Search' and the resource 'Spotify'. It is concise and free of unnecessary words, earning its place.
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?
For a search tool with no output schema and no annotations, the description is too minimal. It does not explain how results are returned, how to handle no results, or how this integrates with sibling tools like getPlaylistTracks, leaving significant gaps for the agent.
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 schema covers all parameters with descriptions (100% coverage), so the tool description does not need to add parameter information. However, the schema's limit description says '10-50' while the minimum is 1, and the tool description does not clarify this inconsistency.
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?
Description uses the specific verb 'Search' and explicitly enumerates the item types (tracks, albums, artists, playlists). This clearly distinguishes it from sibling tools like getPlaylistTracks or playMusic, which focus on different actions.
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 implies the tool is for searching Spotify content but provides no explicit guidance on when to use it versus alternatives. It does not mention related workflows, exclusions, or prerequisites such as authentication via getAccessToken.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral disclosure. It states the action ('adds') but does not clarify whether items are appended to the queue, whether an active device is required, what occurs if the item is unavailable, or any side effects. This lack of detail is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word contributes meaning; there is zero waste or repetition.
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?
Given the tool's simplicity, the description is adequate for basic understanding. However, with no output schema or annotations, it lacks important operational context such as prerequisites (active device), whether the operation replaces or appends to the queue, and error behavior. This leaves room for ambiguity in real-world usage.
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 schema provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no extra semantics beyond referencing the item types, which aligns with the 'type' enum. It does not clarify the relationship between id, uri, and type, but the schema already handles that adequately.
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 uses a specific verb 'Adds' and identifies the exact resource 'playback queue', while also enumerating the accepted item types (track, album, artist, playlist). This clearly distinguishes it from sibling tools like addTracksToPlaylist (which targets a playlist) and playMusic (which initiates playback).
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 implies the use case: when you want to place an item into the playback queue rather than playing it immediately or adding to a playlist. However, it does not explicitly state when to prefer this tool over siblings like playMusic or addTracksToPlaylist, nor does it mention any prerequisites such as an active device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to explain how the optional deviceId interacts with 'active device', or what happens if no device is active or playback is already paused. Auth requirements and error behavior are also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and exactly as concise as needed. Every word earns its place.
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?
For a simple pause tool, the description is minimal but sufficient at a basic level. However, it lacks guidance on device selection, idempotent behavior, and return values, which would be valuable for an agent with no annotations.
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 covers deviceId with 'The Spotify device ID to pause playback on' (100% coverage). Description adds little beyond that, and the phrase 'active device' may conflict with specifying a deviceId. No added clarity on when to provide the parameter.
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 states a specific verb ('Pause') and resource ('Spotify playback on the active device'), clearly distinguishing it from sibling tools like resumePlayback, playMusic, and skipToNext. No ambiguity.
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?
Usage is implied by the tool name and description: pause when wanting to stop playback. However, no explicit when-to-use guidance or alternatives are mentioned, leaving the agent to infer the context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and doesn't mention prerequisites (e.g., active playback, deviceId optionality), side effects, or edge cases like an empty queue. This is a significant gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and front-loaded with the core action. No wasted words or redundant information.
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?
For a simple one-parameter tool, the description gives the essential purpose, but with no annotations or output schema, it lacks behavioral context such as what happens if no device is specified or whether playback must be active. It is minimally complete for selection but not fully informative.
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 already describes deviceId as 'The Spotify device ID to skip on' with full coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
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 a specific action ('Skip to the next track') on a specific resource ('current Spotify playback queue'). It distinguishes from sibling tools like skipToPrevious by explicitly indicating 'next'.
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 usage context is implied by the action and resource, but there is no explicit guidance on when to use this tool versus alternatives like skipToPrevious or pausePlayback. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key side effect: updating spotify-config.json, which is beyond what the tool's name implies. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention error handling, token expiry behavior, or whether user interaction is required, making it only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficiently structured and front-loaded with the primary action. It contains no filler or redundant information; every word contributes to understanding the tool's purpose and side effect.
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?
There is no output schema, so the description should clarify what the tool returns. It mentions fetching tokens but does not state whether they are returned to the caller or only written to the config file. This ambiguity is significant for an authentication tool that likely feeds into other operations. The description is incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. The description clarifies that credentials are sourced from spotify-config.json, which explains why no parameters are needed. This adds meaning beyond the empty schema, aligning with the baseline of 4 for no-parameter tools.
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 tool's function: fetching a valid Spotify access token and refresh token using credentials from spotify-config.json, and updating that file. It uses a specific verb ('fetches') and resource ('Spotify access token', 'spotify-config.json'), distinguishing it from sibling tools like refreshAccessToken which focus on refreshing an existing token.
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?
No guidance is provided on when to use this tool versus alternatives such as refreshAccessToken. It does not specify whether this is for initial authentication, re-authentication after expiry, or setup. The description lacks any explicit context or exclusion criteria, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only restates the purpose and adds 'current user's', but doesn't disclose behavior like authentication requirements, pagination, default limit, or whether the returned playlist objects contain tracks. This is a gap for a read operation with no other context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It delivers the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the core functionality and context. However, it lacks any mention of authentication or return format, but given the tool's simplicity and the presence of sibling auth tools, the description is mostly complete. It earns a 4, not a 5, due to minor gaps.
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% for the single 'limit' parameter, which has a description ('Maximum number of playlists to return (1-50)'). The description does not add anything beyond the schema, so the baseline of 3 applies.
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 action ('Get') and the resource ('a list of the current user's playlists on Spotify'), which distinguishes it from siblings like searchSpotify or getPlaylistTracks. It's specific and unambiguous.
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 implies usage (when you need the current user's playlists), but it doesn't explicitly state when to prefer this over alternatives like searchSpotify, nor does it mention exclusions (e.g., 'not for playlists of other users'). The context is clear, but no explicit guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries full responsibility. It discloses the dependency on spotify-config.json and that the operation is an 'attempt', but it does not state whether the token is persisted, whether the operation overwrites the config file, or what happens on success or failure. For a mutation-like operation, this lack of side-effect disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the verb and object. Every word contributes meaning; there is no filler or redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description gives the essential purpose and data source. It lacks discussion of side effects or prerequisites, but the simplicity of the tool partially compensates. It is sufficient for basic understanding though not rich in operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to describe. The description appropriately references the refresh token source (spotify-config.json), which adds context beyond the empty schema. The baseline of 4 for zero-param tools is applied.
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 identifies the action ('refresh'), the target ('Spotify access token'), and the mechanism ('using the refresh token from spotify-config.json'). This distinguishes it from sibling getAccessToken, which likely retrieves the current token. The verb and resource are specific and unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives such as getAccessToken. It does not mention token expiration conditions, whether it should be called before other API operations, or prerequisites like the existence of spotify-config.json. The usage context must be inferred from the verb 'refresh'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the core action but does not disclose what happens at the start of the queue, whether a deviceId is required, or potential error conditions. The basic behavioral trait of changing playback is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the verb and resource without any tangential information.
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?
For a simple tool with one optional parameter and no output schema, the description covers the primary action but lacks usage context, such as when to prefer this over 'skipToNext' or prerequisites. It is adequate but not thorough.
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 schema already fully describes the single parameter (deviceId) with 100% coverage. The description does not add any additional meaning about the parameter, such as its optionality or behavior when omitted. Baseline 3 is appropriate since the schema handles it.
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 uses a specific verb ('Skip') with a clear resource ('previous track') and context ('in the current Spotify playback queue'). It clearly distinguishes from the sibling 'skipToNext' by specifying 'previous'.
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 implies when to use (when wanting to go backward in the queue) but does not explicitly mention alternatives like 'skipToNext' or any prerequisites such as an active playback session. No exclusions or when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Get', but does not explicitly state that it has no side effects, requires active playback, or what happens if nothing is playing. The description adds minimal behavioral context beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose without any fluff or redundancy. Every word earns its place, and the information density is high.
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?
The tool is simple (no parameters, no output schema), but the description is somewhat thin. It does not specify what 'information' is returned (e.g., track name, artist, album) or address edge cases like no active playback. For a simple read tool, this is moderately complete but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description correctly avoids inventing any. With no parameters, the schema coverage is effectively 100%, and the baseline of 4 applies. The description does not need to add parameter-level detail.
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 'Get' and the resource 'currently playing track on Spotify', which directly and unambiguously describes the tool's purpose. It is distinct from sibling tools like getRecentlyPlayed or searchSpotify, as it specifically targets the current playback state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently playing' provides clear context that this tool is for retrieving live playback information, implicitly distinguishing it from search or playlist retrieval. However, it does not explicitly mention when not to use it or reference alternative tools, falling short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-spotify-server MCP server](https://glama.ai/mcp/servers/JKGzenna/mcp-spotify-server/badges/card.svg)](https://glama.ai/mcp/servers/JKGzenna/mcp-spotify-server)

Score Badge

Copy to your README.md:

[![mcp-spotify-server MCP server](https://glama.ai/mcp/servers/JKGzenna/mcp-spotify-server/badges/score.svg)](https://glama.ai/mcp/servers/JKGzenna/mcp-spotify-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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