@striderlabs/mcp-spotify

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes (search, playlist, playback, device, auth categories). Minor overlap exists between get_playlists and search_playlists, and between spotify_status and get_currently_playing, but descriptions help differentiate.
Naming Consistency3/5
The majority follow a consistent verb_noun pattern in snake_case (search_artists, create_playlist, set_volume). However, the auth tools (spotify_status, spotify_auth, spotify_logout) break the pattern with an inconsistent 'spotify_' prefix, and a few names like 'spotify_auth' are not purely verb-first. This is a moderate deviation that could be easily fixed.
Tool Count4/5
With 19 tools, the server sits at the upper boundary of what's comfortable, but the count is justified by covering distinct areas like search, playlist, playback, devices, and auth. It feels slightly heavy but not bloated, as each tool addresses a specific function without redundancy.
Completeness3/5
Core workflows are covered: search, playlist CRUD (though no read single playlist or delete), basic playback control, and device management. Missing features include shuffle/repeat, fetching playlist contents, queue management, and detailed track/album context, which are notable gaps for some use cases. Overall, it's functional but not exhaustive.
Average 3.9/5 across 18 of 19 tools scored. Lowest: 3.2/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
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the operation and return fields, omitting authentication requirements, read-only status, pagination behavior, and any side effects. This is minimal disclosure beyond the action itself.
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 two short sentences, front-loaded with the core action and followed by a concise list of returned data. Every word contributes, with no redundancy or filler.
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 2-parameter search tool with no output schema, the description adequately states the operation and enumerates return fields, which helps compensate for the missing output schema. However, it omits authentication prerequisites and available query qualifiers (e.g., artist:, year:) that the schema only partially covers.
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 100% of parameters with descriptions and an example for query plus a range for limit. The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for songs on Spotify') and enumerates the returned fields. It identifies a distinct resource from sibling tools, but does not explicitly contrast with search_artists/search_albums/search_playlists, so differentiation is implicit.
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 about when to use this tool versus the sibling search tools (e.g., search_artists, search_albums, search_playlists), nor any mention of when not to use it. The intended use case is only implied by the tool name and the schema's example query.
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 states the basic action but does not explain what happens at the end of the queue, whether playback state changes (e.g., paused vs. playing), or whether an active device is required.
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 with no filler or repetition. It is appropriately sized for the tool's low complexity.
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 is minimally viable, but it omits useful contextual details such as how deviceId affects the action and what happens if no device is active or the queue is empty. Given the absence of an output schema and annotations, a bit more behavioral context would be expected.
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% for the single optional deviceId parameter, which already explains it comes from get_devices and falls back to the active device. The description adds no parameter-level meaning, but the high schema coverage justifies the baseline score of 3.
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') and clearly identifies the target resource ('the next track in the queue'). It also inherently distinguishes itself from the sibling tool previous_track by specifying direction.
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 previous_track, play, or get_currently_playing. It also does not mention prerequisites like an active device or how the optional deviceId interacts with the operation.
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?
The description mentions the output fields but does not disclose details about the return structure, potential errors, authentication requirements, or rate limits. With no annotations provided, the description carries the full burden and falls short of fully informing the agent about behaviors.
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 concise and straightforward, consisting of two sentences that directly convey the purpose and output. No unnecessary fluff or redundancy is present.
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 description covers the core functionality and mentions the output fields, but it does not detail the exact JSON structure, pagination behavior, or error handling. Given the simplicity of the tool, this may be adequate but lacks completeness for a fully self-contained description.
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 parameter descriptions in the schema already cover the meaning of 'query' and 'limit'. The tool description does not add further clarification or constraints, so it provides no added value beyond what the schema already gives.
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 purpose: searching for playlists on Spotify. It also specifies the returned fields (name, owner, track count, URI), making it distinct from sibling search tools like search_artists or search_albums.
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 does not provide explicit guidance on when to use this tool over alternatives. While it is clear that it is for playlists, it lacks any mention of scenarios where this tool is preferred or not, which is important given the existence of sibling search tools.
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 does not disclose any behavioral traits beyond what is inherent to a search (e.g., pagination, sorting, or authentication needs). Since there are no annotations, the description carries the burden, but it only states results are returned without detailing limitations or side effects. It's adequate for a simple read-only search, but lacks extra context.
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?
The description is concise: a single sentence with a clear verb and a list of return fields. It is front-loaded with the core purpose and adds useful details about the output. While it could be slightly more structured, it earns high marks for efficiency.
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 that the tool has a simple schema (2 params, fully documented) and no output schema, the description provides a reasonable overview of return fields. However, it omits important context like pagination, authentication requirements, or rate limits, which might be relevant for use. It's 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 input schema already describes both 'query' and 'limit' with examples and default values, so schema coverage is 100%. The description only mentions 'Returns...' without adding parameter-specific meaning. Thus, the description adds minimal value beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for albums') and the resource ('albums on Spotify'). It specifies the return fields (album name, artists, release date, track count, and URI), which helps distinguish it from sibling tools like 'search_tracks' and 'search_artists'. However, it doesn't explicitly differentiate from 'search_playlists' or other search tools, but the resource is clear enough.
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 a basic search use case but provides no explicit guidance on when to use this tool versus alternatives like 'search_tracks' or 'search_artists'. It doesn't mention exclusions or alternative tools, but the straightforward nature of a search tool makes the usage context somewhat clear.
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, the description must convey behavioral traits. It does state the tool removes tracks, implying a mutating operation, but does not disclose details like whether it's reversible, requires specific permissions, or how it handles invalid URIs. This is a moderate disclosure but insufficient for a mutating tool without annotations.
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 one sentence, perfectly concise and front-loaded. It conveys essential information without any fluff, making it easy for an agent to parse.
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 with 2 params, 100% schema coverage, and no output schema, so the description need not explain return values. However, it could mention that removal is permanent or that at least one URI is required, but the schema already marks both as required. Overall adequate but not rich.
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% and the parameter descriptions are brief but clear. The description adds no extra meaning beyond what's in the schema, so the baseline of 3 applies. It doesn't clarify URI format or playlist ID source beyond the schema's 'from get_playlists' hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove) and the resource (tracks in a playlist), specifying the input type (Spotify track URIs). It distinguishes from siblings like add_to_playlist, though it doesn't explicitly name alternatives.
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 it (when removing tracks from a playlist) but does not provide explicit guidance on when not to use it or mention alternatives. It lacks context on prerequisites like needing the correct playlist ID and valid URIs.
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 full burden for behavioral disclosure. It only states the mutate action ('Add') and does not mention side effects, ordering behavior beyond the schema, ownership requirements, or response structure. This is a significant transparency 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 two short sentences, front-loaded with the primary verb and resource, and contains zero fluff. Every phrase earns its place, providing the minimum useful guidance without redundancy.
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 relatively simple 3-parameter tool with full schema descriptions, the description is mostly adequate. It covers the action and the source of track URIs. It could have mentioned ownership/auth implications or return values, but the lack of an output schema and the simplicity of the operation keep this from being a critical gap.
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%, so the schema already documents all parameters. The description adds a small amount of value by specifying the URI format ('spotify:track:...') and suggesting they come from search results, but it does not compensate beyond that baseline.
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 opens with 'Add one or more tracks to a playlist,' a specific verb+resource combination that clearly states the core action. It also distinguishes itself from sibling tools like remove_from_playlist and create_playlist by implying the target is an existing playlist and the action is additive.
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 instruction 'Use track URIs from search results' establishes a clear context: this tool is used after searching for tracks, implying you should call search_tracks first. However, it does not explicitly state when not to use this tool or mention alternatives like remove_from_playlist for the opposite operation.
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, the description carries the full transparency burden. It discloses the mutation effect and return values, but does not mention authentication requirements, permission expectations, or potential side effects beyond creating the playlist. This is adequate but leaves gaps.
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?
Two short sentences with the verb and resource front-loaded, no filler, and no redundant statements. Every word earns its place.
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 three-parameter create tool with fully described schema and clear return values, the description is substantially complete. It lacks only broader context like auth prerequisites or relationship to other playlist tools, but those are inferable from sibling names.
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?
Input schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter semantics beyond naming the resource; it does not clarify default visibility or description formatting beyond what the schema provides.
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 opens with a specific verb and resource ('Create a new playlist in your Spotify account') and states the return value (playlist ID and URI). This clearly distinguishes it from sibling playback and playlist search tools.
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 action itself implies when to use it, but there is no explicit when-to-use guidance, no prerequisites such as authentication, and no mention of alternatives. Sibling tools like get_playlists and add_to_playlist are distinct enough that the absence is not fatal, but the guidance is minimal.
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 must carry the full burden of behavioral disclosure. It discloses the returned data components (name, artists, progress, device, shuffle state, repeat state), which gives some expectation of output. However, it omits edge-case behavior such as what happens when nothing is playing, whether an active device is required, or whether the operation may fail—leaving a gap in transparency.
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 that states the action and specific return values without any fluff or repetition. Every word contributes meaning, achieving high conciseness and clear structure.
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?
Given the tool's zero parameters and lack of output schema, the description is largely complete for selection and invocation. It lists the key return fields, so an agent knows what to expect. It would benefit from a note on edge cases (e.g., no track playing), but for a simple read-only getter, it is sufficiently complete.
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 the schema is trivially 100% covered. The baseline for 0 params is 4, and the description adds no conflicting or redundant parameter info. It instead clarifies the tool's output, which is useful since there is no output schema.
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 specifies the action (Get) and the resource (currently playing track), and enumerates the exact fields returned (name, artists, progress, device, shuffle state, repeat state). This distinguishes it from siblings like 'spotify_status' or 'get_devices' by focusing on the current playback track details.
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 offers no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or preferred contexts. With many related sibling tools (play, pause, get_devices), the lack of usage direction leaves the agent to infer appropriateness without support.
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, the description carries the full burden. It discloses a key constraint (Premium account) and the effect (set volume), but does not mention behavior like applying to the active device, side effects on current playback, or failure modes when no device is active. The schema partially covers device behavior, but the description adds little beyond the action itself.
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 that conveys the core action and a key requirement in under ten words. Every word earns its place, with no redundancy or unnecessary detail.
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 two-parameter setter with a fully described schema and no output schema, the description is sufficient to convey the primary purpose and a critical prerequisite. It lacks some detail about device selection and failure behavior, but these are partially covered by the schema, and the tool's simplicity does not demand extensive elaboration.
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%, with clear descriptions for both deviceId and volumePercent. The description adds only the parenthetical range (0-100%), which is already present in the schema, so it provides no additional semantic value beyond the structured definitions.
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 ('Set') and resource ('playback volume') with an explicit range (0-100%). It is immediately distinct from the sibling playback controls like play, pause, and next_track, leaving no ambiguity about what the tool does.
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 direct 'when to use' guidance or alternatives are stated. The only guidance is the prerequisite 'Requires a Spotify Premium account,' which implies usage but does not explain how this tool fits among playback controls or when one might prefer it.
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?
There are no annotations to indicate safety or side effects. The description only states that it lists devices, but does not disclose whether it requires authentication, whether it changes any state, or any other behavioral aspects. This lack of transparency is a concern.
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 directly states the function. It is well-structured and to the point.
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?
Given the absence of parameters and output schema, the description is adequate. It covers the essential aspect of what the tool does. However, it could mention any prerequisites or typical usage scenarios, but that is not critical for a simple listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is complete. There is nothing to explain, and the description does not mislead about parameters.
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: listing all available Spotify Connect devices. It also specifies the information returned (IDs, names, types, and active status), making its purpose 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 does not explicitly state when to use this tool versus alternatives. However, given that it is a simple listing tool, the context implies it is for retrieving device information, but it lacks explicit guidance on when to choose it over other playback-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the search behavior and enumerates the return fields ('artist name, genres, popularity, followers, and URI'), which communicates that this is a read-only lookup. It could add more context such as authentication requirements or result paging, but the core behavior is clear.
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?
The description is concise: two short sentences communicating the action and return fields with no redundant wording. It could be slightly richer, but every phrase earns its place.
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 two-parameter search tool, the combination of description and schema covers purpose, parameters, and return high-level input fields. The lack of an output schema is partially compensated by listing the fields; it could still mention that results are an array or require authentication, but it is reasonably complete.
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 fully describes both parameters ('query' and 'limit'), including default and range. The description adds no extra parameter detail, so it stays at the baseline for high 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 identifies the specific action ('Search') and the target resource ('artists on Spotify'), and lists the returned fields. This clearly differentiates it from sibling tools like search_albums, search_tracks, and search_playlists.
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 finding artists, but it does not explicitly state when to use it versus other search tools or exclude album/playlist/track searches. There is no mention of alternatives or prerequisites.
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 explains the main behavior (start/resume) and the no-URI fallback, which is useful. However, it does not mention device-related failure modes, authorization requirements, or what happens if no active device is available, leaving some behavioral ambiguity.
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 two sentences, front-loaded with the core action, and contains no redundant or filler text. Every sentence contributes a meaningful behavioral detail.
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 player control tool with no output schema and well-documented parameters, the description covers the essential behaviors and common use cases. It could add more about device handling or edge cases, but the schema and sibling context mitigate those 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 description coverage is 100%, so the schema already documents all five parameters. The description adds minimal parameter-level meaning beyond restating that URIs can be tracks, albums, artists, or playlists. It does not significantly enhance the schema-provided semantics.
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 with a specific verb ('Start or resume playback') and identifies the resource types it can play (track, album, artist, playlist URI). It also distinguishes itself from sibling tools like pause, next_track, and previous_track by focusing on starting or resuming playback.
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 description provides clear usage context: play specific URIs or resume playback if no URI is provided. It does not explicitly name alternatives or exclusion conditions, but the behavior is obvious enough given the sibling tools and the explicit resume behavior.
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 discloses the action and the source of device IDs but omits potential side effects (e.g., whether playback state changes, authentication requirements, or errors). It is adequate for a simple operation but lacks depth expected for a mutation tool without annotations.
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?
Two short, direct sentences, immediately stating the action and the key dependency. Every word adds value, with no fluff or redundancy. Perfectly sized for a tool with only two parameters.
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?
Given the simplicity of the tool (2 params, no nested objects, no output schema), the description is mostly sufficient. It explains the core operation and the source of valid device IDs. A slightly more detailed note about the 'play' parameter's effect might improve it, but the schema already covers that. Overall, complete for its complexity.
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%, so the baseline is 3. The description's reference to get_devices reinforces the schema's deviceId description but does not add new semantic meaning beyond what is already in the schema. No extra detail about the 'play' parameter is provided, but the schema already explains 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 clearly states the tool's action ('Transfer playback') and resource ('to a different Spotify Connect device'), distinguishing it from sibling tools like play/pause or volume control. The phrase 'different' implies switching devices, which aligns with the tool's name and function.
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?
Provides clear context on how to use the tool ('Use device IDs from get_devices'), indicating a prerequisite dependency. However, it does not explicitly mention when not to use it or contrast with alternative tools like 'play' or 'pause', so it lacks explicit exclusions. Still, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the key behavioral nuance: the tool restarts the current track if playback is more than 3 seconds in, which is critical for the agent to predict the outcome. It doesn't mention other behaviors like whether it pauses or stops, but for a simple media control, this is adequate.
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 two sentences, front-loaded with the primary purpose, and the second sentence adds a crucial behavioral detail. Zero waste, perfectly concise.
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?
Given the tool's simplicity (one optional parameter, no output schema, no nested objects), the description is complete enough. It covers the main action and the key edge case (3-second rule). It doesn't describe return values, but since there's no output schema, that's not required. The only minor gap is not mentioning what happens if there is no previous track, but that's a minor omission for a media control tool.
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% (the only parameter deviceId is described as 'Device ID (from get_devices). Uses active device if omitted.'). The description adds no additional parameter semantics beyond what the schema provides, 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 the tool's purpose: 'Go back to the previous track.' It uses a specific verb ('go back') and resource ('previous track'), and the additional detail about restarting the current track if more than 3 seconds in distinguishes it from a simple 'previous' command and from sibling tools like next_track.
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 description provides clear context on when to use the tool (to go back to the previous track) and includes a specific behavioral condition (if more than 3 seconds in, restarts current track first). It doesn't explicitly mention when not to use it or alternatives, but the context is clear enough given the sibling tools (e.g., next_track for forward).
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 full burden of behavioral disclosure. It explains that the tool checks login status and shows the connected account, but it does not describe potential failure modes, network dependencies, or the exact format of the response. Basic behavior is clear, but richer context about side effects or preconditions is missing.
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 two sentences, front-loaded with the main purpose, and every word adds value. It avoids redundancy and effectively communicates the essential information in a compact form.
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?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description provides sufficient context: it states what the tool does, what it reveals, and when to call it. While a more detailed return value description could be added, it is not necessary for an agent to understand and correctly invoke this straightforward status check.
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 the schema is fully comprehensive. The description correctly avoids describing any parameters, and with 0 parameters, a baseline score of 4 is appropriate since there is no need for additional parameter explanation.
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 'Check Spotify authentication status' with a specific verb and resource, and it explicitly distinguishes itself by showing login state and connected account. It is distinct from sibling tools like spotify_auth and spotify_logout, making its purpose unambiguous.
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 description gives an explicit directive to 'Call this first before using other tools,' providing clear when-to-use guidance. However, it does not explicitly mention when not to use it or contrast it with alternative authentication tools like spotify_auth, though the context makes this implied.
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 does not disclose potential side effects, error conditions (e.g., what happens if no active device exists), or any permissions required. It is minimal but not misleading.
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 one concise sentence that covers the main action and the optional parameter. It is well-structured and free of unnecessary detail.
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 pause action, the description is adequate. It does not mention output or error handling, but the absence of an output schema and the straightforward nature of the tool make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a clear description for the deviceId parameter, including its source ('from get_devices') and default behavior ('Uses active device if omitted'). This fully explains the parameter's meaning.
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: 'Pause playback on the active device or a specified device.' It is specific and distinguishes from sibling tools like play, next_track, etc.
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?
While the description does not explicitly contrast with alternatives, it provides sufficient context by mentioning when a device is specified versus omitted. It is clear when to use this tool (to pause), but lacks explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the action (get) and the return fields. It says 'all playlists' but the limit parameter suggests a maximum, which is discussed. No annotations provided, but the description is transparent about what is returned.
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?
The description is concise and to the point, but could be structured with more details on the return format or pagination. However, it's not overly verbose.
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?
The description mentions it's for the user's library surfaces, but doesn't specify authentication or error responses. However, schema provides a parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, limit, with a clear description including range and default value. No ambiguity.
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 what the tool does (gets all playlists in the user's Spotify library) and exactly what it returns (names, IDs, and URIs). The scope is explicitly defined as 'owned and followed' playlists, leaving no ambiguity about the purpose.
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 description specifies the content (owned and followed playlists) and the parameter, but does not mention authentication requirements or typical usage patterns. However, given the context of sibling tools like spotify_auth, it's implied. It could be more explicit about the need for prior authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: opens a browser window, requires user authorization, and stores tokens locally. It also notes the tool is only needed once, implying idempotence. It does not mention potential delays or failure modes, but for this simple auth tool, it is sufficiently 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 two sentences, immediately front-loading the purpose and then adding essential details (browser, env var, one-time need). Every word earns its place; no fluff.
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?
Given the tool's simplicity (no params, no output schema), the description is largely complete. It covers what, how, and prerequisites. It could briefly link to sibling tools (e.g., 'after this, you can use Spotify search and playback tools'), but that is a minor gap. The mention of local token storage implies persistence.
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 the input schema is trivially complete. The description adds context about the OAuth flow and environment variable, which is useful but not strictly parameter-related. Baseline for 0 params is 4, and this description meets it without exceeding.
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 authenticates with Spotify using OAuth 2.0 with PKCE and opens a browser for authorization. It is distinct from all siblings, which focus on music actions, and specifies the resource (Spotify) and action (authenticate).
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 description implies this is a prerequisite for other Spotify tools by stating 'Only needed once — tokens are stored locally.' It also mentions the required SPOTIFY_CLIENT_ID environment variable. However, it does not explicitly say 'use this before other Spotify tools if not authenticated,' but the context makes that obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that it clears stored OAuth tokens, which is a key behavioral side effect. It doesn't detail server-side invalidation or whether user data is affected, but the token clearing is adequately 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?
Two concise sentences that clearly state the action and its use cases. No redundancy or fluff; structure is optimal.
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?
The description covers purpose and usage, but lacks mention of side effects (e.g., whether it invalidates server-side tokens) or guidance on what to do after logout (e.g., re-authenticate). However, for a simple logout, it's reasonably complete, and no annotations are provided to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema shows no parameters (empty object). The description correctly does not invent any parameter details. Since there are no parameters, no additional semantics are needed; the schema already conveys all parameter info, and the description aligns.
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 purpose: logging out of Spotify by clearing OAuth tokens. It uses a specific verb ('Log out') and resource ('Spotify'), and distinguishes itself from sibling tools like spotify_auth by explicitly mentioning token clearing.
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?
It explicitly states use cases ('to reset authentication or switch accounts'), providing clear context for when to invoke. However, it does not mention when not to use it or suggest alternatives like spotify_auth for logging in, though the purpose is clear enough to infer exclusivity.
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 MCP server](https://glama.ai/mcp/servers/markswendsen-code/mcp-spotify/badges/card.svg)](https://glama.ai/mcp/servers/markswendsen-code/mcp-spotify)

Score Badge

Copy to your README.md:

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

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/markswendsen-code/mcp-spotify'

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