spotify-library-mcp

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Most tools have a clear resource-and-action boundary: playlist operations, Liked Songs operations, search, snapshots, and stats are generally easy to tell apart. A few pairs such as search/find_track and dedupe_report/summarize_playlist overlap conceptually, but the descriptions clarify their distinct purposes.
Naming Consistency4/5
The dominant pattern is verb_noun: list_playlists, create_playlist, add_tracks, remove_saved_tracks, get_top_tracks. Minor outliers like playlist_diff, changes_since, and rediscover break the pattern slightly but do not make the set confusing.
Tool Count3/5
27 tools is on the high side, and several reporting, snapshot, and utility tools overlap in broad purpose. The platform supports a wide library-management workflow, so most tools are defensible, but the set would benefit from some consolidation.
Completeness4/5
The set covers playlist CRUD, liked-songs management, search, library summaries, deduplication, backups, and listening history. Missing playlist operations like reordering tracks is a noticeable but non-critical gap; the core workflows do not dead-end.
Average 3.3/5 across 27 of 27 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior1/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 simply says 'Search Spotify' and reveals nothing about response format, pagination, default behavior, side effects, rate limits, or whether it queries the Spotify API for catalog items. This does not satisfy behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than genuine conciseness. The single sentence conveys no actionable information beyond the tool name, and it is not structured in a way that surfaces key choices like type or pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, an enum, a default, and no output schema, this description is not nearly complete. An agent cannot safely know what this tool returns, how to scope results, or what constraints apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining what query, type, and limit mean. The description contains no parameter information at all, leaving agents to rely entirely on the schema without added semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Search Spotify,' is essentially a restatement of the tool's name with only the Spotify resource added. It gives no indication of what is being searched (tracks, albums, playlists) and does nothing to differentiate this generic 'search' name from siblings like find_track or find_in_playlists.
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 about when to use this tool versus alternatives. It does not mention the available entity types, the intended use cases, or when to prefer sibling tools like list_playlists or find_track.
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 present, the description carries the full burden of behavioral disclosure, but it only supplies a noun phrase. It gives no hints about recency window, count limits, ordering, or whether the operation is a read. The elliptical phrasing could even be mistaken for a data label rather than an operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tiny, but this is under-specification rather than conciseness. It front-loads nothing meaningful beyond the tool name and has no structural benefit.
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?
Given one parameter with no schema coverage, no output schema, and no annotations, the description fails to give the agent enough context to infer return shape, edge cases, or authentication implications. A single sentence with operational details would be a major improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the limit parameter, but it says nothing about it. The agent has only the raw schema (default 50, max 50) and no clue what values mean for pagination or required behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recently played tracks.' is essentially a tautology that restates the tool name. It contains no verb and never says what the operation does — list, fetch, return, etc. It also does nothing to distinguish this tool from siblings like get_playlist or get_top_tracks.
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 get_top_tracks or find_track. There is no mention of context, prerequisites, or exclusions. This leaves an agent to guess which tool fits the user's intent.
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. 'Create' conveys the essential mutation, but nothing is said about idempotency, duplicate name behavior, visibility defaults, or response output. The description offers only the most basic side effect.
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 a single sentence with no filler or redundant material. It is front-loaded with the primary action, though the extreme brevity does contribute to the overall incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 3-parameter mutation tool with no annotations and no output schema, yet the description gives no essential context such as public defaulting to false, whether description is optional, or what the return value is. The tool is not adequately specified for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting parameter meaning, but it does not mention any of the three parameters. An agent must infer the meaning of 'name', 'public', and 'description' solely from property names and schema types, with no added guidance.
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 uses a clear verb and resource: 'Create a new playlist for the user.' It is specific enough to indicate the core operation, but it does not distinguish itself from closely related sibling tools like merge_playlists, which also creates a playlist. It is clear, but no explicit sibling differentiation is provided.
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 such as update_playlist, merge_playlists, or add_tracks. Contextual prerequisites or conditions (e.g., whether a playlist must not already exist) are completely absent.
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 behavioral disclosure burden. It mentions that results are the most-played artists, but gives no information about ordering, return shape, authentication expectations, defaults to interpreted time_range, pagination-like behavior, or side effects.
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 extremely succinct and front-loads the core resource. No words are wasted, though the minimalism edges toward under-specification rather than elegant brevity.
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 tool with no annotations, no output schema, and two parameters whose semantics are not described, the description is too thin. An agent can infer that it fetches top artists, but it is not told how the time range changes the data or how to choose parameters appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about the meaning or effect of 'limit' or 'time_range'. While the schema lists valid enums and defaults, the description does not help an agent understand what short_term versus long_term means or how limit affects the result.
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 phrase 'The user's most-played artists' clearly identifies the resource being retrieved, and the tool name supplies the get action. It distinguishes itself from sibling tools like get_top_tracks by naming artists specifically, but it is still a noun phrase rather than an explicit statement of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of alternatives such as get_top_tracks, get_recently_played, or get_saved_tracks. The description gives no context for choosing among the many sibling music-retrieval tools.
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 behavior, but it only states a simple fact about the returned data. It does not mention that this is a read-only operation, what the result looks like, how time_range affects results, or any authentication or rate-limit expectations.
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 a single, concise sentence withno fluff or repetition. It front-loads what the tool is about. However, it offers no structure or additional detail, and its brevity edges toward under-specification rather than fully informative conciseness.
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?
Given no annotations, no output schema, and no param descriptions, this minimal statement is not complete enough to let an agent confidently select and invoke the tool in all cases. An agent would need to infer behavior, expected output shape, and the meaning of time_range from external knowledge, which is too much context to omit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two parameters, and the description does not compensate by explaining limit or time_range. The parameter names and enum values give some hint, but the description adds no meaning beyond what is already minimally inferable from the schema.
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 states that this tool returns the user's most-played tracks, which clearly identifies the resource and the kind of data provided. It is not a tautology of the tool name and is enough to distinguish it from artist- or playlist-related siblings, though it never explicitly says 'get' or 'list'.
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 given about when to use this tool versus alternatives like get_top_artists, get_recently_played, or get_saved_tracks. The context is weakly implied by the phrase 'most-played,' but there is no explicit condition for choosing this tool over its siblings.
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, so the description must carry the full burden of behavioral disclosure. It does hint at a read-only comparison by describing diff categories, but it never explicitly states that playlists are not modified, what the output shape is, or how duplicates are handled. This is insufficient for a tool with no annotation safety net.
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 extremely short and to the point, capturing the core result categories without filler. However, its telegraphic syntax creates some ambiguity; it reads more like an output summary than a full description.
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 low complexity with only two string parameters, so a short description is partially acceptable. Yet there is no output schema, and the description does not clarify the return format (e.g., lists vs counts), handle edge cases, or provide enough operational context for an agent to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'A' and 'B' without explicitly defining them as playlist_a and playlist_b or explaining what values to provide. The parameter names are fairly intuitive, but the description does not add enough detail about expected formats, constraints, or whether these are IDs or playlists.
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 identifies the resource (two playlists) and the diff categories it outputs: items only in A, only in B, and a shared count. It is reasonably clear and differentiates this tool from siblings like merge_playlists, but it lacks an explicit verb such as 'returns' or 'computes', which leaves slight ambiguity.
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 given about when to use this tool versus alternatives like find_in_playlists, merge_playlists, or changes_since. There is no mention of prerequisites, comparison behavior, or context in which playlist_diff is the right choice.
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 or hints for a destructive mutation are provided, so the description carries the full burden of behavior disclosure. It only restates the core effect — removing tracks — and says nothing about scope (targeting only the current user's own library), permanent/irreversible nature, handling of already-removed or invalid IDs, error behavior, or what the response looks like.
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 clean, active-voice sentence that states the action and target with zero filler. It is efficient and well formed for a one-parameter tool, though the brevity that earns this score is also what leaves behavioral gaps for other dimensions.
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?
Given this is a destructive mutation with no annotations and no output schema, the description is too thin to be fully actionable. The parameter shape is simple and the scope is hinted, but an agent still has no indication of side effects, return signal, failure modes, or operational prerequisites, so meaningful gap exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only paraphrases the parameter at the tool level ('tracks') without explaining track_ids semantics. It does not clarify the accepted ID format (e.g., Spotify URI vs. raw ID), whether tracks must already exist in Liked Songs, or what the array limits imply in practice.
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?
States the action verb and a specifically named resource, 'Liked Songs', which is the distinct collection this tool targets and tells the agent apart from playlist-based tools like remove_tracks. However, it does not explicitly contrast itself with remove_tracks or state which resource it does not apply to, leaving the disambiguation implicit.
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 intent is implied: an agent thinking 'remove this track from my Liked Songs' can infer this is the right tool, and 'Liked Songs' provides recognizable context. There is no explicit guidance about when not to use it, nor a pointer to alternatives such as remove_tracks, so usage guidance is left to inference.
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 responsibility for behavioral disclosure. Saying 'Remove tracks' implies a mutating/destructive operation, but it does not explain whether the action is irreversible, what permissions are required, whether missing or invalid track IDs are tolerated, or whether duplicate tracks are removed in bulk. This leaves the agent uninformed about side effects.
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, tightly written sentence with no wasted words. It contains the essential action and object, immediately front-loading the primary purpose. For a simple tool, this level of concision is appropriate, even if more behavioral detail is missing.
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?
The tool is simple with only two required parameters and no output schema, but the description still omits meaningful context: what happens if some track IDs are not found in the playlist, whether the playlist must be owned by the user, what is returned after removal, and idempotency of the operation. The one-liner is a base-level operation statement but is not complete enough for correct invocation in varied real-world scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning beyond the property names themselves. The agent must infer that track_ids is an array of track IDs and that playlist_id identifies the target playlist, but no format, source, or validation nuance is explained. With the schema providing only the types and required flags, the description fails to compensate.
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 is specific and unambiguous: 'Remove tracks from a playlist' clearly states the verb (remove), the resource (tracks), and the container (a playlist). This distinguishes it from sibling tools like remove_saved_tracks (saved tracks, not playlist tracks) and delete_playlist (deleting the playlist itself), even without naming them explicitly.
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 gives no contextual guidance about when to use this tool over alternatives. It does not mention when not to use it, prerequisites (e.g., the game user must own the playlist), or how it differs from similar operations like remove_saved_tracks or update_playlist. The agent is left to infer usage entirely from the tool name and one-line description.
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 carry the burd. It clearly indicates a read-like action and that the full track list is included, which is useful. But it does not disclose behaviors such as whether results are paginated, whether large playlists may be truncated, whether authentication is expected, or whether any limitations apply.
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 core purpose and the most distinguishing output ('full track list'). No filler or redundant restatement 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?
With one simple parameter and a clear action, the description is minimally viable. However, there is no output schema and no annotation context, so the description should also clarify anything the agent needs to know about the shape/scope of the response or how this compares to the many sibling tools; it does not fully do that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes a single required playlist_id with no description, and the tool description adds no direct explanation of the parameter, so coverage is effectively 0%. The phrase 'a playlist' loosely maps to playlist_id, but the description does not clarify how the ID is used, where it comes from, or any format expectations.
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 uses a specific verb ('Get'), specifies the resource ('a playlist'), and clarifies output scope ('details and its full track list'). This clearly distinguishes it from list_playlists, which lists playlists rather than a single playlist's tracks, but it does not explicitly name or contrast any sibling tool.
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 many sibling tools such as summarize_playlist, list_playlists, or find_track. The description states what the tool does but gives no context for choosing it over alternatives.
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 present, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state that it is non-destructive, what data is returned, whether pagination applies, or what a 'snapshot' entails in this 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 very short and front-loads the main verb and object. It is appropriately concise for a zero-parameter tool, though it is slightly too terse to provide helpful context beyond the bare operation.
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 no-parameter list operation, this is minimally adequate: an agent knows to call it to get saved snapshots. However, it is missing context about what a snapshot is, how they relate to other snapshot tools, and what the returned data will look like, especially given that there is no output schema.
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 no input parameters, so the absence of parameter details in the description is not a gap. The schema already conveys that there is nothing to configure. No additional parameter explanation is necessary.
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 a specific action ('List') and a specific resource ('saved snapshots'), so an agent can infer the tool's basic purpose. It doesn't explicitly differentiate from sibling snapshot-related tools like snapshot_library or changes_since, but the 'list' verb makes the operation reasonably distinct.
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 instead of alternatives such as snapshot_library or changes_since. The description does not mention any exclusions, prerequisites, or relationship to other snapshot operations.
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 useful filtered behavior: it surfaces liked songs from years ago that are missing from top tracks or recent plays. With no annotations, the burden is fully on the text, but it does not state whether the tool is read-only, modifies anything, or how the rediscovered songs are presented.
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 short and front-loaded with the core idea: old liked songs absent from recent activity. The phrase 'forgotten favourites, spread across artists' is somewhat emotive and not strictly necessary, which keeps it from a perfect conciseness score.
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 annotations, no output schema, and limited parameter description, more operational detail is needed. The text gives a good conceptual summary but does not clarify what the tool returns, whether it mutates anything, or how to relate the result to sibling operations like playlists and saved tracks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the responsibility falls on the description. Only 'years ago' loosely hints at min_years_ago, and the limit parameter is not mentioned at all in prose. The description does not compensate for the absent schema-level documentation.
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 identifies what the tool surfaces: old liked songs that no longer appear in top tracks or recent plays. The exclusion condition helps distinguish it from tools like get_saved_tracks, get_top_tracks, and get_recently_played. However, it lacks an explicit verb such as 'retrieves' or 'returns,' relying on the tool name for the action.
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: for forgotten favorites from past years that are absent from current top/recent activity. It does not name alternatives, state when not to use it, or explain how it complements the sibling tools, so the guidance is more contextual than explicit.
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 correctly indicates this is a mutation operation, but it omits important context such as whether playlist ownership or existing playlists are required, how partial updates are applied, or what the response indicates.
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 single sentence is compact, front-loaded with the action, and contains no filler. It is appropriately sized, though its brevity contributes to the lack of deeper usage and behavior guidance.
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 mutation tool with 4 parameters, no annotations, and no output schema, the description is too thin. An agent would still need to infer preconditions, determinism of the operation, and the meaning of the response, so the description does not fully support correct 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?
The schema has 0% description coverage, so the description must compensate. It does map three parameters to their meaning: name to renaming, description to changing the description, and public to visibility. However, it does not explain playlist_id beyond the schema and provides no detail about how omitted parameters behave, leaving some semantics implicit.
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 identifies the operation: renaming a playlist or changing its description/visibility. It is specific enough to distinguish this from creation, deletion, and track-management tools, though it does not explicitly name any sibling tools or state that it only affects playlist metadata.
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 intended use is implied by describing the exact actions: use this tool when a playlist's name, description, or visibility needs to change. However, there is no explicit guidance about when not to use it, or why an agent should choose this over create_playlist, delete_playlist, add_tracks, or remove_tracks.
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 must carry the full burden of behavioral disclosure. It lists returned statistics but does not state whether the operation is read-only, whether it requires special permissions, how metrics are computed, or what secondary effects might occur. The tool appears non-mutating, but this is never stated.
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 dense sentence that front-loads the target ('Stats for one playlist') and then compactly enumerates the output categories. Every word contributes useful information, with no redundant or filler content.
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?
With only one parameter and no output schema, the description covers the essential purpose and the categories of statistics that may be consumed. An agent can generally infer that calling the tools requires a playlist identifier and yields an aggregating summary. It would benefit from a brief note on parameters or limitations as output, but it is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents only a required 'playlist_id' with a simple string type and no description, while schema_description_coverage is 0%. The description mentions 'one playlist' but never explicitly links it to the playlist_id parameter or explains the expected ID format or source. It therefore provides only minimal compensation for the missing schema-level documentation.
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 identifies the resource ('one playlist') and the specific statistics returned (runtime, top artists, decades, duplicates, over-representation). It does not include an explicit verb but communicates the function effectively and distinguishes this from a library-wide summary tool such as summarize_library.
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 wording 'Stats for one playlist' implies the tool is intended for analyzing a single playlist, but the description provides no definite conditions, alternatives, or exclusions. It does not direct the agent to dedupe_report or summarize_library for related needs, leaving the routing implicit.
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 conveys important matching behavior (ignoring remaster/edit suffixes) and implies that the tool is a report rather than an actual removal, but it never explicitly states that no changes are made. With no annotations, the description carries the full burden of disclosing side effects, so the ambiguity about whether it is read-only or returns a list without modifying anything prevents a higher score.
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 very short and contains no filler, capturing the essential matching rule, scope, and output. However, it is a fragment rather than a complete sentence, and the phrase 'Duplicate tracks' could be misread as a command to duplicate tracks. Still, it is compact and front-loaded.
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 zero-parameter report tool, the description states the scope (each playlist), the matching logic, and the output (ids to remove). But because there is no output schema or annotations, the description must clarify the return format and side effects; it does not explicitly say whether this is a read-only list and what the exact response structures. This is a meaningful gap, yet the core intent is adequately conveyed.
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 no parameters and an empty input schema, so there is no parameter documentation gap. The schema description coverage is 100%, providing a safe baseline of 4; the description does not introduce any conflicting parameter information.
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 identifies the resource (duplicate tracks inside each playlist) and the deliverable (ids to remove), and the key matching rule is specified. It is clear enough to distinguish from siblings like remove_tracks and merge_playlists, but it lacks an explicit verb like 'report' or 'find', which slightly weakens the clarity from a 5.
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 gives no explicit guidance on when to use this tool versus alternatives such as remove_tracks or summarize_playlist. There is no mention of preconditions, exclusions, or situations where a different tool would be more appropriate. The purpose is somewhat implied by the wording, but the description does not direct the agent to use the right sibling.
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 and no output schema, the description must carry the behavioral burden. It says only that the result is 'All tracks the user has Liked,' and does not disclose pagination, result limits, read-only behavior, or anything about how the tracks are returned.
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 highly concise, front-loads the core scope, and contains no filler words. Every word contributes to the meaning.
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 zero-parameter tool, the description provides enough to understand the basic operation, but without annotations or an output schema it does not disclose pagination or response shape. The agent can still invoke the tool correctly with no arguments, but may be surprised by the result format.
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?
There are zero parameters and the input schema covers the parameter space completely, so a parameter explanation is unnecessary. The no-parameter baseline of 4 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 identifies the resource ('tracks') and the scope ('user's Liked'), so an agent can tell this returns liked/saved tracks. It lacks an explicit verb like 'get' or 'list', and it does not explicitly differentiate itself from sibling tools such as get_top_tracks or get_recently_played.
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 wording implies it should be used when the agent needs the user's liked tracks, but there is no explicit when-to-use guidance or mention of alternatives. It neither states exclusions nor provides conditions for choosing a sibling tool.
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 burden of explaining behavior. It only states that the action is an addition; it does not disclose whether repeated saves are idempotent, whether limits other than the schema's 200-item cap affect behavior, what side effects occur, or what the response will be. This is minimal for a mutating 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 with no filler. Every word contributes to stating the operation's purpose, so it 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 very simple one-parameter tool, the description is minimally viable: it states the action and the target resource, and the schema covers the parameter shape. Still, with no annotations or output schema, some useful context is absent, such as that the operation targets the current user's library and how duplicate or already-saved tracks are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description overlaps semantically but does not add meaningful parameter details. It does not explain what format track_ids entries should take, such as Spotify track IDs versus URIs, or whether duplicate IDs are allowed. The only added signal is that the parameter refers to tracks.
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 says exactly what the tool does: 'Add tracks to the user's Liked Songs' with a specific verb and resource. It also distinguishes this from sibling tools like add_tracks, which implies use on playlists rather than the Liked Songs collection.
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 is implied clearly: use this when the user wants to store tracks in their Liked Songs. However, it does not explicitly mention alternatives such as add_tracks, remove_saved_tracks, or get_saved_tracks, nor does it state when not to use this tool.
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 behavioral burden. It clearly indicates this is an informational read about API limits and does not perform mutations. However, it does not mention output format, side effects, or whether it contacts Spotify, leaving some transparency 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?
A single concise sentence that front-loads the core purpose ('what this app can and cannot do') and adds clarifying detail in a parenthetical. No filler words or redundant information.
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 getter, the description is reasonably complete: it states the subject and the reason for limitations. It could specify the output shape, but the absence of parameters and output schema makes this less critical.
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?
There are zero parameters, so the description needs to add no parameter meaning. The baseline of 4 applies, and the description gives relevant context about the resource being queried.
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?
Describes the tool's scope: it states the app's capabilities and limitations, specifying that it relates to endpoints removed/renamed by Spotify for new apps. It is not a tautology and is distinct from the sibling tools, though it lacks an explicit verb/command.
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 implies the tool should be consulted to understand app limitations, but it provides no when-to-use versus alternative guidance. There is no mention of contexts where this should be checked first or how it differs from related budget/search 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 behavioral burden. It clearly communicates what the tool reports (playlist changes, per-playlist track changes, and like changes) and the default snapshot behavior. It does not mention permissions, rate limits, or a side-effect profile, but the wording strongly suggests a read-only comparison utility and the core behavior is well disclosed.
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 compact sentence that front-loads the core behavior and then enumerates the specific result categories with no filler. Every word contributes.
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 small tool with one optional parameter, the description covers default invocation and makes the return content reasonably clear through the labeled change categories. However, without an output schema or annotations, and without describing how snapshot values relate to sibling snapshot tools, the agent still has to infer important context about how to pick a snapshot and what 'latest' means.
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 schema has only a bare 'snapshot' string property, yet the description explains that the parameter selects a snapshot and that the default is the latest snapshot. This adds real meaning beyond the schema, though it could go further by explaining how to obtain a snapshot ID (for example, via list_snapshots or snapshot_library).
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 identifies the tool's resource ('changes since a snapshot') and enumerates the exact categories it reports: playlists created/deleted/renamed, tracks added/removed per playlist, likes added/removed. It is close to a 5 but phrased as a fragment/question rather than a clear imperative, and it does not explicitly distinguish itself from sibling snapshot/diff tools.
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 phrase 'since a snapshot' and the 'latest' default imply the intended use case, but there is no explicit guidance about when to use this tool instead of siblings like playlist_diff, snapshot_library, or list_snapshots. The description leaves the agent to infer the difference between comparing against a snapshot and other comparison utilities.
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?
Since no annotations are provided, the description carries the full behavioral burden. It explicitly reveals the destructive nature and the crucial irreversibility for owned playlists, which is the most important safety-relevant behavior. It omits permission requirements or effects on collaborators, but the core risk is clearly disclosed.
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?
One sentence contains the action, scope, and an important qualification. It is front-loaded, wastes no words, and conveys the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with one parameter and no output schema, the description covers what happens, the library context, and irreversible consequences. No extra return-value detail is needed, and the agent has enough to call the tool safely.
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 0%, so the description must compensate for the single parameter. It confirms that the parameter identifies a playlist from the user's library, but does not detail the expected format, source, or ownership implications of playlist_id beyond its schema name.
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 ('Remove') and identifies the exact resource ('a playlist from the user's library'). The parenthetical '(unfollow)' and the irreversibility statement help distinguish this from similar operations like remove_tracks or update_playlist.
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?
There is no guidance on when to choose this tool over alternatives such as remove_tracks, update_playlist, or create_playlist. It does not state preconditions like playlist ownership or when removal from the library is appropriate, leaving routing decisions to the agent.
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 bears most of the burden for behavioral disclosure. It exposes useful non-obvious context such as a potential Spotify search ban and cache size, but it does not explicitly state that the tool is read-only or whether calling it consumes search quota. That is not a contradiction, but a behavioral 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?
Two tightly-worded sentences: the first lists the exact data exposed and the second states perfectly useful timing. No filler words or redundant 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 zero-parameter status check, the description tells the agent what data will be available and when to call it. It does not specify exact value formats or the meaning of 'cache size' or 'ban active,' but the context is sufficient to make an informed use decision.
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 takes zero parameters and the schema has full coverage. There is no parameter-level meaning for the description to add, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the tool's resource: remaining search calls, cache size, and search ban status for today. It communicates the information returned, and it is naturally distinct from siblings such as get_api_limits or search. A slightly more explicit verb like 'returns' or 'reports' would make the purpose even stronger.
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?
'Check before bulk searching' gives a direct, actionable usage context. It does not mention when NOT to use this tool, nor explicitly differentiate from get_api_limits, but the usage cue is 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 provided, the description must carry the behavioral burden. It discloses that the tool writes a snapshot to disk and that it enables changes_since, which are useful side effects. However, it does not clarify label behavior, whether snapshots are named automatically, whether existing snapshots are overwritten, or what the tool returns.
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 high information density. The main action is stated up front, and the two ancillary details (backup and enabling changes_since) are integrated without waste.
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 tool is simple: one optional parameter, no output schema, no annotations. The description explains the core operation and the implied prerequisite for changes_since. It is largely complete, but the lack of any description of 'label' prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, label, and the description says nothing about it. Schema description coverage is 0%, so the description needed to explain the meaning and purpose of label but did not. An agent cannot know why they would supply a label or what format/constraints apply.
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 (Save), a specific resource (full snapshot of all playlists + liked songs), and the destination (disk). It also explains the purpose (backup; enables changes_since), which distinguishes it clearly from siblings like list_snapshots or changes_since.
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 implicitly tells the agent this should be run before using changes_since and positions the tool as a backup operation. It doesn't explicitly name alternatives or say when not to use it, but the context is clear and sufficient for this simple tool.
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 behavioral disclosure burden. It openly states the mutation ('Add') and a key behavioral detail—duplicates are skipped automatically. It does not mention authorization or failure modes, but the duplicate semantics are a valuable disclosure.
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?
One compact sentence carries the noun, verb, target resource, accepted formats, and a deduplication guarantee. There is no wasted text and every clause adds information.
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 two-parameter mutation tool without an output schema, this description is near-complete: it captures the operation, the accepted input, and the important duplicate-handling behavior. It omits permission requirements and error cases, but those are common to such tools and the operation is simple enough that the model can proceed confidently.
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 0%, so the description must compensate. It clarifies that track_ids accept either IDs or spotify:track URIs and implies playlist_id refers to the target playlist. However, it does not explicitly map each parameter to its schema property or explain expected ID formats in detail.
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: add tracks to a playlist, identifies the resource (playlist) and explicitly welcomes both track IDs and spotify:track URIs. It distinguishes itself from remove_tracks and save_tracks, but it does not directly reference a sibling, so it stops slightly short of a 5.
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 context is clear: use this when you want to add tracks to an existing playlist, with duplicate-skipping behavior. It does not explicitly name alternatives or state when not to use it, but the operation is specific enough for an agent to infer appropriate usage.
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 full responsibility for behavioral disclosure. It clearly indicates a read-style list operation and adds the useful scoping detail that both owned and followed playlists are included. Yet it does not mention return shape, ordering, or pagination, which is typical for list endpoints.
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?
A single, well-constructed sentence with no filler or repetition. It front-loads the action and immediately clarifies the inclusion of followed playlists.
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, zero-parameter list operation, the description gives enough context to select and invoke the tool correctly. The main omission is the return contract: with no output schema, an agent cannot know what fields or pagination information to expect, but this is a minor gap for such a simple tool.
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 baseline of 4 applies; there is simply no parameter meaning for the description to add. The word 'all' reinforces that the call is intentionally unparameterized.
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 ('List'), the target resource ('playlists in the user's library'), and the scope ('owned and followed'). This lets an agent distinguish it from tools like get_playlist (single playlist) or create_playlist (write operation) without needing to inspect other schemas.
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 intended use is implied from the phrase 'List all playlists' — use it when a broad, unfiltered playlist enumeration is needed. However, it does not explicitly contrast with siblings like find_in_playlists, summarize_library, or get_saved_tracks, nor does it specify when not to use it.
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 full burden. The health/counts/stats framing implies a read-only analysis, but it never explicitly states that it has no side effects, or whether it consumes significant API time/budget in the presence of get_api_limits/get_search_budget siblings. It does disclose what data it examines, which is useful.
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?
One dense purpose line plus a short directive sentence, with the headline information front-loaded and zero filler (there is a typo, but structurally it's tight).
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 analysis tool, the description adequately covers inputs (none), analysis scope (which checks), and when to run it (before reorganisation). It leaves the return format and potential cost underscored, but these are minor given the simplicity of the invocation surface.
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?
With zero parameters and 100% schema coverage, the description need not document inputs. The 'whole-library' framing still adds the implicit meaning of what the analysis rangers over, so it adds value even though there are no inputs to explain.
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 a clear subject ('Whole-library health') and then lists the specific categories covered, giving the agent a concrete idea of its outputs. The 'whole-library' scoping distinguishes it from sibling tools like summarize_playlist, dedupe_report, and playlist_diff even though those aren't explicitly named.
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?
'Use before any reorganisation' is a direct and actionable when-to-use directive. It doesn't list alternatives or exclusions by name (e.g., when to prefer summarize_playlist), but the scoping already implies those boundaries.
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 must carry the behavioral burden. It discloses the key side effects: creating/using a target playlist, deduplicating tracks, and optionally deleting sources. It does not cover reversibility or permission requirements, but the destructive behavior is surfaced.
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?
One sentence conveys the action, destination options, deduplication behavior, and optional source deletion. It is front-loaded, focused, and contains no filler.
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 gives a reasonable mental model, but for a mutating tool with no annotations and no output schema, it omits key invocation details: how target_id and new_name relate, whether delete_sources removes entire source playlists, and what the tool returns. These gaps can affect correct usage.
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 schema has 0% description coverage, so the description must compensate for parameter meaning. It maps source_ids, target_id, new_name, and delete_sources into plain-language concepts. However, it does not clearly specify whether target_id and new_name are mutually exclusive or how conflicts are resolved.
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 a specific verb and resource: merge several playlists into one existing or new target. It also names deduplication and optional source deletion, distinguishing it clearly from sibling tools like add_tracks and delete_playlist.
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 intended use case is explicit: combine multiple playlists into a single playlist, optionally with deduplication and source deletion. It does not mention alternatives or exclusions, but the consolidation context is clear enough to guide selection.
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 behavioral disclosure. It reveals that matching can happen by name/artist substring, ID, or URI, and that Liked status is included. This is sufficient for a read-oriented search tool, though it does not describe response details or side effects.
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?
A single sentence delivers the operation, the search input format, and the extra Liked behavior without filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and no nested schema. The description covers the key user intent and the accepted query forms. Additional output-shape details or rate-limit caveats could improve completeness, but nothing essential is missing for selection and invocation.
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 schema provides no description for the required `query` parameter, but the tool description compensates by explaining that the query can be a name/artist substring, an ID, or a URI. This gives an agent enough context to construct the parameter correctly.
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 operation: find which of the user's playlists contain a given track. It also distinguishes this from similar-looking siblings like find_track by focusing on playlist membership and Liked status rather than general track search.
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 use case is clearly conveyed: when you need to know where a track lives across the user's playlists and whether it is Liked. It does not explicitly name alternative tools or provide when-not-to-use guidance, so it does not reach a 5.
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?
Even though no annotations are provided, the description discloses key behavioral traits: it verifies the artist on the result and returns null when no verified match exists. This gives the agent essential runtime expectations without needing to infer them.
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 zero fluff. The primary purpose is front-loaded, and the second sentence adds the critical return behavior. 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?
The description is mostly complete for a simple two-parameter lookup: it explains the search intent, the verification constraint, and the null case. It does not detail the shape of the returned track, but 'find one track' plus null-on-no-match is sufficient for typical invocation.
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?
With 0% schema description coverage, the description must carry the meaning of the parameters. It does this by tying 'track' and 'artist' to the verification behavior: track is the requested song, and artist is the verification criterion that must appear on the result.
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 action ('Find one track') with a concrete verification behavior ('verifying the artist is on the result'). It also names the problem it solves ('avoids karaoke/cover mismatches'), clearly distinguishing it from a more generic search tool.
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 clearly implies when to use this tool: when you need a single track and want to ensure the artist actually matches, avoiding karaoke/cover versions. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to choose this over generic search.
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:

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

Score Badge

Copy to your README.md:

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

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/oliver-virt/spotify-library-mcp'

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