Spotify MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as get_album vs get_album_tracks or add_to_playlist vs add_to_queue. However, some overlap exists, like remove_from_playlist and remove_tracks, which could cause confusion about whether they affect playlists or the user's library. The descriptions help clarify, but the similar naming and overlapping concepts present minor ambiguity.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern throughout, such as get_album, create_playlist, and search_tracks. The naming is highly predictable and readable, with no mixing of conventions or inconsistent verb styles. This uniformity makes it easy for agents to understand and predict tool functions.
Tool Count2/5
With 41 tools, the count is excessive for a single server, making it feel heavy and potentially overwhelming for agents. While Spotify's API is extensive, many tools could be consolidated (e.g., multiple search tools or overlapping get functions). A more focused set of 15-25 tools would be better scoped for coherence and usability.
Completeness5/5
The tool surface provides comprehensive coverage of Spotify's core functionalities, including CRUD operations for playlists and tracks, playback control, user profile management, and extensive search capabilities. There are no obvious gaps; agents can perform full lifecycle actions like creating, modifying, and deleting content, along with discovery and analytics, ensuring no dead ends in typical workflows.
Average 4.3/5 across 41 of 41 tools scored.
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 is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 adds useful context about what the tool returns (complete list of categories with names, descriptions, icons, etc.) and mentions requirements (valid Spotify access token, categories reflect current organization). However, it doesn't address important behavioral aspects like rate limits, error conditions, pagination (despite having a 'limit' parameter), or whether this is a read-only operation (though implied by 'get' name).
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 excessively long and repetitive with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, CATEGORY TYPES, ORGANIZATION BENEFITS, USE IN APPLICATIONS, REQUIREMENTS) that contain overlapping information. Many sentences don't earn their place, such as the redundant 'Perfect for building browsing interfaces' and 'Helps users navigate vast music catalogs'. The core information could be conveyed in 3-4 concise sentences rather than this verbose structure.
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 3-parameter tool with no annotations and no output schema, the description provides substantial context about what the tool does and returns. However, it lacks critical information about the output format structure, error handling, and behavioral constraints. The description compensates somewhat for the missing output schema by detailing return content, but doesn't specify the actual data structure or 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?
With 67% schema description coverage (2 of 3 parameters have descriptions), the description doesn't explicitly mention any parameters but provides contextual information that helps understand their purpose. The mention of 'Country code for localized content' in the schema aligns with the description's focus on Spotify's organization. The 'limit' parameter (with no schema description) is somewhat addressed by the description's emphasis on returning 'Complete list' and 'all music categories', though pagination behavior isn't clarified.
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 with specific verbs ('Explore all available music categories') and resources ('Spotify uses to organize and classify playlists and content'). It distinguishes from sibling tools by focusing on categories rather than tracks, playlists, artists, or playback functions. The description explicitly mentions what the tool does in the opening sentence.
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 through extensive use cases (e.g., 'Build category-based music browsing interfaces', 'Discover music genres and style classifications') and application examples ('Create category-based navigation menus', 'Build genre-specific recommendation engines'). However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools for different purposes.
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 of behavioral disclosure. It does well by specifying authentication requirements ('Valid Spotify access token with user-library-read scope'), data scope ('Complete collection of user's liked/saved tracks'), return format details ('Track information with save dates and timestamps'), and ordering ('Chronological order of when tracks were liked'). It doesn't mention rate limits or pagination behavior, but covers most essential behavioral aspects for a read 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 overly verbose with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, PERSONAL COLLECTION, COLLECTION INSIGHTS, REQUIREMENTS) that contain repetitive information. Many sentences don't earn their place - for instance, the 'PERSONAL COLLECTION' and 'COLLECTION INSIGHTS' sections provide motivational context rather than operational guidance. The core purpose could be communicated in 2-3 sentences instead of this lengthy format.
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 read operation with 3 parameters (one undocumented), no annotations, and no output schema, the description provides good coverage of authentication, return data, and use cases. However, it lacks details about pagination behavior (how limit/offset work with the 'Complete collection' claim), error conditions, and exact response structure. The motivational content ('Perfect for building greatest hits playlists') doesn't compensate for these operational 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?
With schema description coverage at only 33% (only the 'token' parameter has a description), the description doesn't compensate by explaining the 'limit' and 'offset' parameters. While it mentions 'Complete collection' and 'Total count,' it doesn't clarify how limit/offset affect pagination. The description adds value about what data is returned but doesn't enhance understanding of the undocumented input parameters beyond what's implied in examples like 'Get my 50 most recently liked 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 clearly states the tool's purpose: 'Access the user's personal collection of liked/saved tracks from their Spotify library.' This is a specific verb ('access') + resource ('liked/saved tracks') combination that distinguishes it from siblings like get_playlist_tracks or get_recently_played. The description explicitly focuses on the user's personal library rather than public content.
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 about when to use this tool through the 'USE CASES' section (e.g., 'Display user's favorite music collection,' 'Create personalized playlists from liked songs'). However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like get_recently_played for recent activity or get_top_tracks for algorithmic favorites). The 'REQUIREMENTS' section adds important prerequisites but not comparative guidance.
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 adds useful context about authentication requirements (Spotify access token) and market availability constraints, but doesn't cover other behavioral aspects like rate limits, error handling, or response format details beyond listing return categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (use cases, returns, examples, insights, requirements), but it's verbose with redundant information. Some sections like 'detailed insights' and 'examples' could be more concise, and the core purpose could be stated more directly upfront.
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 moderate complexity (2 parameters, no output schema, no annotations), the description provides substantial context about what the tool does, use cases, return information, and requirements. It's mostly complete but could benefit from more specific behavioral details like response structure or error scenarios.
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 has 100% description coverage, clearly documenting both parameters (token and trackId). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 with specific verbs ('retrieve', 'get') and resources ('track', 'song'), distinguishing it from siblings like get_album, get_artist, or get_track_lyrics. It explicitly mentions retrieving comprehensive information about specific tracks, which differentiates it from search tools or playlist-related operations.
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 through use cases and requirements, indicating when to use it (e.g., for research, analysis, verification). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, such as using get_album_tracks for album-level details instead.
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 effectively discloses key behavioral traits: it's a read operation (implied by 'Retrieve'), requires authentication ('Valid Spotify access token'), has scope requirements ('user-follow-read'), and includes prerequisites ('User must have followed at least one artist'). It doesn't mention rate limits or pagination behavior, but covers essential operational context.
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 overly verbose with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, MANAGEMENT TIPS, REQUIREMENTS). While structured, it includes extraneous content like 'MANAGEMENT TIPS' that doesn't aid tool selection. The core purpose is front-loaded, but many sentences don't earn their place for an AI agent.
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 no annotations, no output schema, and 2 parameters with 50% schema coverage, the description does a good job covering purpose, usage, and behavioral context. It explains what the tool returns in detail, compensating for the lack of output schema. However, it could better address parameter details or error conditions.
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 50% (only 'token' has a description). The description doesn't explicitly discuss parameters, though examples like 'limit to 50' hint at the 'limit' parameter's purpose. It adds minimal value beyond the schema, which already documents 'token' for authentication and 'limit' with constraints. Baseline 3 is appropriate given partial 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 clearly states the specific action ('Retrieve the complete list of artists that the user actively follows') and resource ('on Spotify'), distinguishing it from sibling tools like get_top_artists or get_artist. The purpose is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides clear context for when to use this tool (e.g., managing followed artists, creating playlists, checking new releases). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, such as get_top_artists for different artist lists.
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 adds useful context like authentication requirements ('Valid Spotify access token with user-top-read scope') and data prerequisites ('Sufficient listening history for accurate results'), but does not cover potential limitations like rate limits, error conditions, or response format details beyond high-level return types.
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 overly verbose and repetitive, with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, TIME PERIODS, LISTENING INSIGHTS, PERSONAL ANALYTICS, REQUIREMENTS) that contain overlapping information. Sentences like 'Perfect for building "best of" personal playlists' and 'Great for music discovery based on your actual preferences' could be condensed without losing meaning.
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 tool with 3 parameters, no annotations, and no output schema, the description provides substantial context: purpose, use cases, return information, examples, time period details, and requirements. It adequately covers the tool's functionality, though it lacks explicit parameter documentation and detailed behavioral traits like error handling.
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?
Schema description coverage is low at 33%, with only the 'token' parameter documented. The description compensates by explaining 'timeRange' options in the 'TIME PERIODS' section and implying 'limit' usage in examples like 'Get my top 20 tracks', though it doesn't explicitly name or detail all parameters. This adds significant value beyond the sparse 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 states the tool's purpose: 'Discover your most listened-to tracks based on actual listening history across different time periods.' It specifies the verb ('discover'), resource ('most listened-to tracks'), and scope ('listening history across different time periods'), distinguishing it from siblings like get_recently_played or get_liked_tracks.
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 for when to use this tool through 'USE CASES' and 'EXAMPLES' sections, such as understanding personal listening patterns or creating summaries. However, it does not explicitly state when NOT to use it or name specific alternatives among siblings (e.g., get_top_artists for artist-focused analysis).
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 of behavioral disclosure. It effectively describes key traits: it's a read-only retrieval tool (implied by 'Retrieve'), mentions external service usage, error handling, instrumental detection, and market availability constraints. It lacks details on rate limits or caching behavior, but covers most essential aspects well.
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 excessively long and repetitive, with multiple sections (USE CASES, WHAT IT RETURNS, EXAMPLES, RESPONSE FORMAT, LYRIC FEATURES, REQUIREMENTS, EXAMPLE RESPONSE FORMAT) that overlap in content. For instance, 'Clean plain text format' is mentioned multiple times. It is not front-loaded; key information is buried in lengthy lists, reducing efficiency for an AI agent.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is quite complete. It covers purpose, usage, behavioral traits, response format with examples, and requirements. However, the lack of an output schema means the description must fully explain returns, which it does adequately but with redundancy, slightly lowering the score.
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 has 100% description coverage, clearly documenting both parameters (token for authentication, trackId for identification). The description does not add any meaningful parameter-specific information beyond what the schema provides, such as format examples for trackId or token validation details, so it meets the baseline but doesn't enhance understanding.
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 with specific verb ('Retrieve') and resource ('plain text lyrics for any Spotify track'), distinguishing it from siblings like 'get_track' (which likely returns track metadata without lyrics) and 'search_tracks' (which searches for tracks). The opening sentence is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides clear context for when to use this tool (e.g., for lyrics analysis, display, or education), and the 'REQUIREMENTS' section lists prerequisites like a valid Spotify token. However, it does not explicitly state when NOT to use it or name alternatives (e.g., using 'get_track' for metadata without lyrics), which prevents a perfect score.
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 and does well by disclosing key behavioral traits: it returns complete lists with specific data fields, includes owned and followed playlists, and has requirements like a valid Spotify token with playlist-read-private scope. It doesn't mention rate limits or pagination details, but covers authentication and scope needs thoroughly.
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 overly verbose with sections like 'MANAGEMENT TIPS' and 'PLAYLIST ORGANIZATION' that don't add essential tool usage information. While front-loaded with core purpose, it includes redundant or tangential content that reduces efficiency, though not misleading.
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 no annotations and no output schema, the description provides substantial context: it details what the tool returns, use cases, examples, and requirements. This compensates well for the lack of structured data, though it could benefit from mentioning error handling or response format specifics.
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 50% (only 'token' has a description). The description adds no explicit parameter information beyond implying retrieval of playlists, which doesn't compensate for the undocumented 'limit' parameter. However, with two parameters and partial coverage, the baseline is met without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'all playlists that the user owns, follows, or has access to in their Spotify library.' It distinguishes from siblings like 'get_playlist' (specific playlist) and 'search_playlists' (search across Spotify), making the scope explicit.
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 CASES' section provides clear contexts for when to use this tool, such as displaying collections or building management interfaces. However, it lacks explicit guidance on when NOT to use it or direct alternatives among siblings, though the purpose clarity implies differentiation.
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 full burden and does well by disclosing key behavioral traits: it specifies authentication requirements ('Valid Spotify access token with user-read-private scope'), privacy considerations ('Respects user privacy settings'), and what information is returned. It doesn't mention rate limits or error handling, but covers essential operational context.
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 excessively long with repetitive sections ('USE CASES', 'WHAT IT RETURNS', 'EXAMPLES', 'PROFILE INSIGHTS', 'PERSONALIZATION OPPORTUNITIES', 'PRIVACY CONSIDERATIONS', 'REQUIREMENTS'). Many sentences don't earn their place—for example, the personalization and insights sections largely restate earlier points. It's front-loaded but bloated overall.
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 moderate complexity (1 parameter, no output schema, no annotations), the description is quite complete. It covers purpose, usage, returns, examples, requirements, and privacy. The main gap is the lack of output schema, but the 'WHAT IT RETURNS' section compensates adequately by listing return data types.
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 has 100% description coverage, so the baseline is 3. The description doesn't add parameter-specific details beyond what's in the schema (the token parameter is documented there). However, it reinforces the authentication requirement in the 'REQUIREMENTS' section, which provides context but not new parameter 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 purpose with specific verbs ('retrieve comprehensive information') and resources ('current Spotify user's profile, preferences, and account details'). It distinguishes from sibling tools by focusing on user profile data rather than music content, playlists, or playback controls.
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 CASES' section provides clear context for when to use this tool (displaying user info, personalization, verification, etc.). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools, though the distinction is implied by the focus on user data versus music content.
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 full burden and does well by disclosing key behavioral traits: real-time availability status, active device indication, volume control capabilities, device restrictions, and authentication requirements. It doesn't mention rate limits or error conditions, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While well-structured with clear sections, the description is quite lengthy with multiple detailed bullet lists. Some information (like specific device types and extensive use cases) could be more concise. The core purpose is front-loaded, but subsequent sections contain some 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 read-only tool with no output schema, the description provides excellent context about what the tool returns, use cases, and requirements. It covers authentication needs, return data structure, and practical applications. The main gap is lack of output format details, but otherwise quite 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 has 100% description coverage, clearly documenting the single 'token' parameter. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 with specific verb ('Retrieve') and resource ('all available Spotify-connected devices for the user's account'). It distinguishes itself from siblings like get_currently_playing or transfer_playback by focusing on device enumeration rather than playback control or content retrieval.
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 through USE CASES and DEVICE MANAGEMENT sections, showing when this tool is appropriate (e.g., for device selection UIs, monitoring availability). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools for similar purposes.
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 and does so well. It discloses behavioral traits like maintaining playback position, queue state, and requiring an active session and specific permissions, which are crucial for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but includes extensive sections (USE CASES, WHAT IT RETURNS, etc.) that, while informative, could be more concise. Some sentences, like in 'PAUSE BENEFITS', repeat information without adding new value.
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 no annotations, no output schema, and a mutation tool with 2 parameters, the description is fairly complete. It covers purpose, usage, returns, examples, benefits, and requirements, though it could benefit from more detail on error handling or output specifics.
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 both parameters. The description adds no additional meaning beyond the schema, such as explaining token scope details or deviceId behavior, but meets the baseline for high 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 clearly states the tool's purpose with a specific verb ('Pause') and resource ('current music playback'), and distinguishes it from siblings like 'resume_player' by specifying it maintains position and queue state. The title being null doesn't affect this clarity.
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 CASES' section provides clear contexts for when to use the tool, such as during calls or for smart home triggers. However, it lacks explicit guidance on when NOT to use it or direct alternatives among siblings, though 'resume_player' is implied as a counterpart.
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 and adds significant behavioral context beyond the input schema. It details return values (e.g., confirmation, updated playlist length), cleaning features (e.g., maintains integrity, preserves order), and requirements (e.g., access token scopes, ownership needs). It does not mention rate limits or error handling specifics, but covers key operational aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like 'USE CASES' and 'REQUIREMENTS', but it is overly verbose with redundant points (e.g., maintenance tips repeat use cases). Sentences like 'Perfect for playlist maintenance and curation' add little value, and the front-loaded purpose is diluted by excessive bullet points that could be condensed.
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 complexity (mutation with 3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, returns, examples, and requirements, though it lacks details on error scenarios or edge cases. The absence of an output schema is partially compensated by describing return values, but some gaps remain for full agent understanding.
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 has 100% description coverage, so the baseline is 3. The description adds minimal parameter-specific semantics, only implying in examples that 'trackUris' can be single or multiple tracks and in requirements that URIs must match exactly. It does not elaborate on format details or constraints 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?
The description clearly states the specific action ('Remove unwanted tracks') and resource ('from any playlist that the user owns or can modify'), distinguishing it from sibling tools like 'add_to_playlist' or 'remove_tracks' by focusing on playlist-specific removal. The title 'remove_from_playlist' reinforces this purpose without redundancy.
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 for when to use this tool through 'USE CASES' and 'MAINTENANCE TIPS' sections, such as cleaning up outdated songs or removing duplicates. However, it does not explicitly state when NOT to use it or name alternatives like 'remove_tracks' (a sibling tool), leaving some ambiguity about tool 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 full burden of behavioral disclosure. It effectively describes key behaviors: it's a write operation ('adds', 'creates permanent'), has authentication requirements ('Spotify access token'), includes rate limits ('maximum 50 tracks per request'), and explains outcomes ('tracks appear in Liked Songs', 'enables offline playback'). It doesn't mention error handling specifics or idempotency, but covers most critical aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but is overly verbose. Several sections like 'BUILDING YOUR COLLECTION' and 'COLLECTION STRATEGIES' contain redundant motivational content that doesn't add essential operational information. The core functionality could be communicated in half the length without losing value.
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 write operation with no annotations and no output schema, the description provides substantial context: clear purpose, usage scenarios, return information, examples, requirements, and limitations. It covers authentication, market restrictions, and rate limits. The main gap is the lack of output schema, but the 'WHAT IT RETURNS' section partially compensates by describing expected responses.
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 both parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema - it mentions 'track IDs' in examples and 'Spotify access token' in requirements, but doesn't provide additional syntax, format details, or constraints. This meets 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 clearly states the tool's purpose with specific verbs ('add tracks', 'save tracks') and resources ('user's personal library', 'permanent collection'). It distinguishes from siblings like 'add_to_playlist' (which adds to playlists, not the library) and 'get_liked_tracks' (which retrieves, not saves). The title 'save_tracks' aligns perfectly with the described functionality.
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 contexts through 'USE CASES' and 'COLLECTION STRATEGIES' sections, explaining when to use it (e.g., saving discovered tracks, building libraries). It implicitly distinguishes from alternatives like 'add_to_playlist' by focusing on permanent library saves, but doesn't explicitly state when NOT to use it or name specific sibling tools as alternatives.
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 adds useful context beyond basic functionality, such as specifying that results are 'limited to public playlists only' and require a 'valid Spotify access token'. However, it lacks details on rate limits, error handling, or pagination behavior, leaving gaps for a mutation-free but API-dependent tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like 'USE CASES' and 'SEARCH STRATEGIES', but it is overly verbose with redundant information (e.g., 'DISCOVERY BENEFITS' repeats points from other sections). Sentences like 'Access to expertly curated music collections' could be condensed, and the front-loaded purpose is clear but followed by excessive elaboration that doesn't always add critical value.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, examples, and requirements, but lacks details on output format (beyond a high-level 'WHAT IT RETURNS' list) and error cases. For a search tool with no output schema, more specifics on return structure would enhance completeness, but it's adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% description coverage, with the 'limit' parameter missing a description. The description compensates by implying usage of 'keywords, themes, or specific criteria' for the 'query' parameter and mentioning authentication via 'Valid Spotify access token' for 'token', but does not explicitly detail parameter interactions or the 'limit' parameter's role. Since there are 3 parameters and the schema coverage is moderate, the description adds meaningful value, though not fully comprehensive.
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: 'Search for public playlists using keywords, themes, or specific criteria to discover curated music collections.' It specifies the verb ('search'), resource ('public playlists'), and scope ('discover curated music collections'), and distinguishes it from sibling tools like 'search_albums', 'search_artists', and 'search_tracks' by focusing exclusively on playlists.
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 for when to use this tool through 'USE CASES' and 'SEARCH STRATEGIES' sections, which outline scenarios like discovering playlists for moods or genres and strategies like using activity keywords. However, it does not explicitly state when not to use it or name alternatives (e.g., 'search_music' or 'search_tracks'), which prevents a score of 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?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies authentication requirements ('Valid Spotify access token with appropriate scopes'), market availability constraints ('Album must exist and be available in user's market'), and what the tool returns (detailed in 'WHAT IT RETURNS'). It does not mention rate limits or error handling, but covers essential operational 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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, REQUIREMENTS) and front-loaded with the core purpose. It is appropriately sized but could be slightly more concise by integrating some details (e.g., examples might be redundant with schema). Most sentences earn their place by adding context.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, usage, returns, examples, and requirements. However, it lacks explicit guidance on alternatives among siblings and does not detail output structure or error cases, which slightly limits completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (token and albumId). The description adds minimal value beyond this, mentioning the token in 'REQUIREMENTS' and albumId implicitly in examples, but no additional semantics like format details or usage tips. This meets the baseline of 3 when schema coverage is high.
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 with specific verbs ('retrieve comprehensive information') and resource ('specific album from Spotify'), and distinguishes it from sibling tools like get_album_tracks (which focuses only on tracks) and search_albums (which searches rather than retrieves a specific album). The title 'get_album' is accurately expanded in the description.
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 for when to use this tool through the 'USE CASES' section (e.g., checking album details, getting track listings). However, it does not explicitly state when NOT to use it or name alternatives among siblings (e.g., get_album_tracks for just tracks, search_albums for discovery), which prevents a perfect score.
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 full burden and does an excellent job disclosing behavioral traits. It explains the 'SMART PLAYBACK' logic (automatically selects best match, prioritizes popular versions, starts on active device), fallback behavior, error handling, and return values. It also specifies authentication requirements and device prerequisites. The only minor gap is not explicitly stating whether this is a read-only or mutation operation, though 'begin playback' implies mutation.
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 excessively verbose with redundant sections. While well-structured with clear headings, it repeats similar concepts across 'USE CASES', 'WORKFLOW OPTIMIZATION', and 'INSTANT GRATIFICATION'. Many bullet points could be consolidated (e.g., 'Perfect for hands-free music control' and 'Ideal for voice and automation interfaces' convey similar ideas). The core functionality is buried among marketing language rather than being front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description provides substantial context about behavior, requirements, and use cases. It explains what the tool returns, error handling, and practical considerations. The main gap is the lack of output schema, but the description compensates well by detailing return values in the 'WHAT IT RETURNS' section. Given the complexity of combined search+playback functionality, it's mostly 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?
With 100% schema description coverage, the baseline is 3. The description adds some context about the 'query' parameter ('Search query should be specific enough for good matching') and implies the 'token' is for Spotify authentication, but doesn't provide significant additional semantics beyond what's already in the schema descriptions. The value added is minimal given the comprehensive 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 clearly states the tool's purpose as searching for a track and beginning playback in one operation. It distinguishes from siblings like 'search_tracks' (which only searches) and 'start_playback' (which only plays) by combining both functions. The opening sentence 'Instantly search for a track and begin playback in one seamless operation' provides specific verb+resource differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives through the 'USE CASES' section (e.g., 'Voice-activated music requests with instant playback', 'Quick music access without browsing interfaces') and 'WORKFLOW OPTIMIZATION' section ('Eliminates manual track selection step'). It also specifies when NOT to use it in 'REQUIREMENTS' (needs active device, specific query). The context clearly differentiates from sibling tools that handle separate search or playback functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly describes behavioral traits: it returns confirmation, updated playlist details, and error information; adds tracks to the end of playlists; supports bulk additions; and outlines prerequisites like authentication and access rights. This covers mutation effects, output format, and operational constraints effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), which aids readability. However, it is overly verbose with repetitive or tangential content (e.g., 'CURATION TIPS' and 'ADDITION FEATURES' include non-essential advice like 'Test songs before adding'), reducing efficiency. Some sentences do not earn their place for core tool understanding.
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 no annotations and no output schema, the description compensates well by detailing return values (confirmation, playlist updates, errors) and behavioral aspects. It covers authentication needs, access requirements, and market restrictions. However, it could be more concise and lacks sibling tool differentiation, slightly impacting completeness for a mutation tool with rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with parameters 'token', 'playlistId', and 'trackUris' well-documented in the schema. The description adds minimal extra semantics (e.g., 'Spotify access token' and 'Spotify playlist ID or URI' are restated), but it implies usage context through examples and requirements. This meets the baseline for high schema coverage without significant enhancement.
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 adds tracks to existing playlists, specifying 'one or more tracks' and 'any existing playlist that the user owns or can modify.' It distinguishes from sibling tools like 'create_playlist' (which creates new playlists) and 'remove_from_playlist' (which removes tracks), making the purpose specific and differentiated.
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 for when to use this tool through 'USE CASES' (e.g., building playlists, adding recommended tracks) and 'REQUIREMENTS' (e.g., valid Spotify token, user ownership/access). However, it lacks explicit guidance on when not to use it or direct alternatives (e.g., vs. 'add_to_queue' for immediate playback), though the use cases imply curation scenarios.
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 full burden and does well: it discloses authentication needs (Spotify access token), access constraints (public or user-accessible playlists), and return content (metadata, tracks, metrics). It doesn't mention rate limits or pagination, but covers key behavioral aspects for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it's verbose with redundant information. Some content (e.g., 'Perfect for playlist curation') is promotional rather than essential. It could be more concise while maintaining clarity.
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 no annotations and no output schema, the description compensates well by detailing return values, use cases, and requirements. It covers authentication, access, and output content thoroughly. However, it lacks explicit error handling or pagination details, leaving minor gaps for a comprehensive retrieval 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%, so parameters are fully documented in the schema. The description adds no specific parameter semantics beyond what's in the schema (e.g., no format examples for playlistId). It mentions requirements that relate to parameters but doesn't enhance their meaning, meeting 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 clearly states the tool retrieves comprehensive playlist information including tracks, metadata, and creator details. It specifies the exact resource (Spotify playlist) and distinguishes from siblings like get_playlist_tracks (which might only return tracks) and get_user_playlists (which lists playlists rather than details of one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with dedicated sections: 'USE CASES' lists specific scenarios, 'PLAYLIST INSIGHTS' suggests optimal contexts, and 'REQUIREMENTS' states prerequisites. It implicitly distinguishes from alternatives by focusing on comprehensive retrieval rather than partial data or actions like create_playlist.
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 of behavioral disclosure. It effectively describes what the tool returns (detailed track information), maintains playlist order, and includes requirements like authentication tokens and rate limits. It doesn't explicitly state if it's read-only or has side effects, but 'Get' implies safe retrieval, and the requirements section covers practical constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like USE CASES and WHAT IT RETURNS, but it's overly verbose with redundant sections (e.g., TRACK DETAILS repeats return information). Some sentences, like 'Perfect for playlist analysis and music research,' add little new value. It could be more front-loaded and concise without losing clarity.
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 complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, returns, examples, and requirements. However, it lacks explicit details on error handling or pagination for large playlists beyond a brief mention of rate limits, leaving some gaps in operational context.
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 description coverage is 67% (2 out of 3 parameters have descriptions). The description doesn't explicitly mention parameters, but the 'EXAMPLES' section illustrates usage with 'playlistId', and the 'REQUIREMENTS' section implies the need for a 'token'. It adds context for how parameters are used (e.g., playlist IDs or URIs) but doesn't detail the 'limit' parameter 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?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('complete track listing from any playlist'), distinguishing it from siblings like 'get_playlist' (which likely returns playlist metadata) or 'get_liked_tracks' (which retrieves saved tracks). The opening sentence establishes a precise scope for 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides clear context for when to use this tool (e.g., extracting songs, analyzing patterns, creating backups). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among sibling tools, such as 'get_playlist' for metadata-only retrieval or 'search_tracks' for broader searches.
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 of behavioral disclosure and does so effectively. It explains what the tool returns (chronological list with timestamps, track info, play context, device info), mentions partial plays and skips are included, and specifies the approximate limit of 50 tracks. The requirements section clearly states authentication needs (Spotify access token with specific scope).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (use cases, returns, examples, etc.), but it's overly verbose with repetitive content. Sections like 'History Benefits' and 'Rediscovery Opportunities' largely reiterate points already made in 'Use Cases,' making it longer than necessary without adding substantial new 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 read-only tool with 2 parameters and no output schema, the description provides comprehensive context. It explains what data is returned, use cases, examples, behavioral details, and requirements. The main gap is the lack of explicit mention of the 'limit' parameter, but overall it gives the agent sufficient information to use the tool effectively.
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 50% schema description coverage (only 'token' has a description), the description compensates well. While it doesn't explicitly mention the 'limit' parameter, it states 'History shows approximately last 50 tracks played,' which implies a maximum limit. The requirements section clarifies the authentication parameter's purpose 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?
The description clearly states the tool's purpose with specific verbs ('access your complete recent listening history') and resources ('recently played tracks with timestamps'). It distinguishes itself from siblings like 'get_currently_playing' (current track) and 'get_liked_tracks' (saved songs) by focusing on chronological history with timestamps.
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 for when to use this tool through use cases like tracking recent music discovery, rediscovering forgotten songs, and building 'Recently Discovered' playlists. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it requires authentication ('Valid Spotify access token with user-top-read scope'), depends on user data ('Sufficient listening history for accurate results'), and provides insights into return values (e.g., 'Artist names, images, and genre breakdowns', 'Listening statistics'). It does not mention rate limits or error handling, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (USE CASES, WHAT IT RETURNS, etc.), but it is verbose with some redundancy (e.g., examples reiterate use cases). Sentences like 'Analyze your personal listening habits to discover your most played artists over different time periods' are front-loaded and clear, but the overall length could be trimmed without losing essential 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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, parameters, returns, and requirements adequately. However, without an output schema, it could provide more detail on the exact structure of return values (e.g., JSON format), though the 'WHAT IT RETURNS' section gives a good overview.
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?
Schema description coverage is low (33%), with only the 'token' parameter documented in the schema. The description compensates by explaining 'timeRange' options ('short_term', 'medium_term', 'long_term') and their meanings in the 'TIME RANGES' section, and implies 'limit' usage through examples like 'Get my top 10 artists'. It adds meaningful context beyond the schema, though it could explicitly define 'limit' 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 purpose: 'Analyze your personal listening habits to discover your most played artists over different time periods.' It specifies the verb ('analyze', 'discover'), resource ('personal listening habits', 'most played artists'), and scope ('over different time periods'), distinguishing it from siblings like get_artist, get_top_tracks, and get_recently_played by focusing on aggregated personal listening data.
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 for when to use this tool through 'USE CASES' (e.g., 'Understanding your personal music taste evolution', 'Creating Year in Music summaries') and 'EXAMPLES' (e.g., 'Who are my top artists this month?'). It implicitly distinguishes from siblings by focusing on personal top artists rather than general artist info or other listening data. However, it does not explicitly state when not to use it or name specific alternatives among siblings.
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 of behavioral disclosure. It effectively describes key behavioral traits: it's a write operation (implied by 'save'), requires specific authentication ('Valid Spotify access token with playlist-modify-public scope'), has limitations on playlist types, and mentions error handling ('Error details for any failed saves'). It doesn't cover rate limits or idempotency, but provides substantial context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (use cases, returns, examples, etc.), but is overly verbose with repetitive information. Sections like 'SAVE FEATURES' and 'TROUBLESHOOTING' contain content already covered elsewhere. While organized, it could be more concise by eliminating 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?
Given the tool's moderate complexity (write operation with authentication requirements), no annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage, limitations, requirements, and troubleshooting. The main gap is the lack of explicit output details beyond high-level descriptions, but overall it's quite complete for agent understanding.
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%, providing clear documentation for both parameters (token for authentication, playlistId for identification). The description adds minimal parameter-specific semantics beyond the schema, mainly reinforcing that 'playlist must be user-created' relates to playlistId validation. This meets the baseline expectation when schema coverage is complete.
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 with specific verbs ('save', 'follow') and resource ('user-created playlist to your Spotify library'). It distinguishes from siblings like 'create_playlist' (makes new) and 'unsave_playlist' (removes), and explicitly differentiates from 'save_tracks' (individual tracks vs. entire playlists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (e.g., 'Add user-created playlists to your library for offline access', 'Follow collaborative playlists') and when not to use it (e.g., 'Cannot save Spotify's official/editorial playlists', 'Only works with playlists created by users'). It also implicitly suggests alternatives like using 'save_tracks' for individual tracks or 'get_playlist' for read-only access.
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 of behavioral disclosure. It effectively describes what the tool returns (track listing, durations, preview URLs, etc.), authentication needs (Spotify access token), and constraints (market availability). However, it doesn't mention rate limits, pagination behavior, or error handling, leaving some gaps for a read operation.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.) and front-loaded with the core purpose. While slightly verbose due to multiple examples and tips, each section adds value without redundancy. It could be more concise by trimming some repetitive examples, but overall it's efficiently organized.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, returns, examples, tips, and requirements. However, without an output schema, it could benefit from more detail on the return structure (e.g., JSON format), and it lacks information on error cases or rate limits, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 out of 3 parameters have descriptions). The description doesn't explicitly discuss parameters, but the 'EXAMPLES' section implies usage of albumId (e.g., 'album ID: 4LH4d3cOWNNsVw41Gqt2kv') and the 'REQUIREMENTS' section mentions the token. However, it doesn't clarify the limit parameter's role or provide additional semantics beyond what the schema offers, resulting in a baseline score.
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 with specific verbs ('retrieve', 'get') and resource ('album tracks'), distinguishing it from siblings like get_album (which likely returns album metadata) and get_track (which returns individual track details). It explicitly mentions 'complete track listing' and 'detailed information about each song', making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance through dedicated sections: 'USE CASES' lists specific scenarios (e.g., building playlists, checking track order), 'TIPS' advises when to use it (e.g., before adding albums to playlists), and 'REQUIREMENTS' states prerequisites (valid token, market availability). This clearly informs the agent about appropriate contexts and constraints.
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 of behavioral disclosure. It effectively describes key behaviors: it returns a ranked list ('Top 10 tracks ranked by global popularity'), includes market-specific variations ('Results can vary by country/region'), and has authentication requirements ('Valid Spotify access token'). However, it lacks details on rate limits, error handling, or pagination, which would be beneficial for a tool accessing external API data.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, etc.), making it easy to scan. However, it is somewhat verbose (e.g., the USE CASES list includes five items, some of which are redundant like 'Quick introduction' and 'Understanding which songs made an artist famous'). While informative, it could be more concise by consolidating similar points.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, return values, examples, market specificity, and requirements. The main gap is the lack of an output schema, but the 'WHAT IT RETURNS' section partially compensates by listing return data types (e.g., 'Track names, album information'). However, it doesn't specify the exact structure or data types of the response, which could be improved.
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 three parameters (token, artistId, country) with clear descriptions. The description adds minimal value beyond this: it mentions 'Use country parameter for region-specific results' and 'Defaults to US market if not specified,' which slightly elaborates on the country parameter but doesn't provide significant additional semantics. This meets the baseline score of 3 when schema coverage is high.
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: 'Discover an artist's most popular and widely-played tracks based on global streaming data.' It specifies the verb ('discover'), resource ('artist's tracks'), and scope ('most popular and widely-played'), distinguishing it from siblings like get_artist_albums (which returns albums) or get_track (which returns a single track).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through dedicated sections: 'USE CASES' lists five specific scenarios (e.g., 'Quick introduction to an artist's biggest hits'), and 'REQUIREMENTS' states prerequisites ('Valid Spotify access token', 'Artist must have released tracks'). It also distinguishes when to use this tool versus alternatives by specifying it returns 'Top 10 tracks ranked by global popularity,' unlike get_top_tracks (which likely returns user-specific top tracks).
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 full burden and does well. It discloses behavioral traits: authentication requirements (Spotify access token with specific scopes), what gets created (new playlist with unique ID, URL, metadata), that it returns an empty playlist ready for track additions, and privacy/collaborative settings. It doesn't mention rate limits or error conditions, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, etc.) but is overly verbose. Some sections like 'CREATION STRATEGIES' and 'PLAYLIST CUSTOMIZATION' contain redundant information. While front-loaded with the core purpose, it could be more concise by eliminating repetitive advice about playlist naming and settings.
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 no annotations, 50% schema coverage, and no output schema, the description provides substantial context: purpose, usage, returns, examples, customization, strategies, and requirements. It covers authentication, behavior, and output details well. However, it lacks explicit error handling information and doesn't fully document all parameters, preventing a perfect score.
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?
Schema description coverage is only 50% (2 of 4 parameters have descriptions). The description compensates by explaining parameter semantics in multiple sections: 'PLAYLIST CUSTOMIZATION' mentions name, description, public/private settings; 'EXAMPLES' shows name usage; 'REQUIREMENTS' covers token authentication. However, it doesn't explicitly map all 4 parameters or explain the 'description' parameter's empty schema description.
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 creates a new custom playlist in the user's Spotify library with specified name and settings. It uses specific verbs ('create', 'build', 'organize') and distinguishes from siblings like 'add_to_playlist' (which modifies existing playlists) and 'get_user_playlists' (which retrieves playlists). The purpose is unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool through multiple sections: 'USE CASES' lists specific scenarios (themed playlists, event collections, collaborative playlists), 'CREATION STRATEGIES' offers tactical advice, and 'REQUIREMENTS' specifies prerequisites. It implicitly distinguishes from sibling tools by focusing on creation rather than modification or retrieval.
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 of behavioral disclosure. It effectively describes what the tool returns (e.g., 'Artist name, biography, profile images'), includes authentication needs ('Valid Spotify access token'), and hints at data source constraints ('Artist must exist in Spotify's database'). However, it lacks details on rate limits, error handling, or pagination, which are minor 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?
The description is well-structured with clear sections (e.g., 'USE CASES', 'WHAT IT RETURNS'), front-loaded with the core purpose, and every sentence adds value without redundancy. It efficiently conveys information in a readable format, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, returns, examples, tips, and requirements. However, without an output schema, it could benefit from more detail on the return structure (e.g., data types), but the 'WHAT IT RETURNS' section mitigates this gap adequately.
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 has 100% description coverage, clearly documenting both parameters ('token' and 'artistId'). The description does not add significant semantic details beyond what the schema provides, such as format examples for 'artistId' or token usage nuances. Thus, it meets the baseline of 3, as the schema does the heavy lifting.
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 with specific verbs ('Get comprehensive information') and resources ('about any artist'), distinguishing it from siblings like 'search_artists' (which searches) or 'get_artist_albums' (which focuses on albums). It explicitly lists what information is retrieved, making the 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through sections like 'USE CASES' (e.g., 'Research artist background before concerts') and 'TIPS' (e.g., 'Use before exploring an artist's full catalog'), which help differentiate when to use this tool versus alternatives like 'search_artists' for discovery or 'get_artist_top_tracks' for specific content. It also includes 'REQUIREMENTS' that specify 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (e.g., 'Complete album listing with release dates and types,' 'Popularity metrics'), authentication needs ('Valid Spotify access token'), and constraints ('Artist must have releases available'). However, it lacks details on rate limits, pagination (implied by 'limit' parameter but not explained), or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (USE CASES, WHAT IT RETURNS, etc.), but it is verbose with repetitive examples and details that could be condensed. Some sentences, like the examples, add value but could be more concise. Overall, it's informative but not optimally 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?
Given the complexity (4 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, usage, returns, examples, and requirements. However, without an output schema, it should ideally detail the response structure more explicitly, though the 'WHAT IT RETURNS' section provides a good overview.
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?
Schema description coverage is 50% (two parameters have descriptions, two do not). The description compensates by explaining 'albumType' in the 'ALBUM TYPES' section, clarifying the enum values beyond the schema. It also implies usage of 'artistId' through examples. However, it doesn't add meaning for 'token' or 'limit' 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?
The description explicitly states the tool's purpose: 'Explore an artist's complete discography including albums, singles, compilations, and appearances.' It uses specific verbs ('explore') and resources ('artist's discography'), and clearly distinguishes from sibling tools like 'get_artist' (which likely gets basic artist info) and 'get_album' (which focuses on a single album).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool through the 'USE CASES' section (e.g., 'Building complete artist discography playlists,' 'Discovering rare releases'), and the 'REQUIREMENTS' section specifies prerequisites ('Valid Spotify access token,' 'Artist must have releases available'). It also distinguishes from alternatives by focusing on discography exploration rather than single albums or tracks.
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 full burden and does so well. It discloses real-time behavior ('Updates instantly as tracks change'), authentication needs ('Valid Spotify access token'), and specific constraints ('User must have an active Spotify session'). It doesn't mention rate limits or error handling, but covers key behavioral aspects thoroughly.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, etc.), but could be more concise. Some sections like 'REAL-TIME FEATURES' and 'EXAMPLES' contain slightly redundant information. Overall, it's front-loaded with the core purpose and each section adds value, though it could be trimmed slightly.
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?
Given the complexity of a real-time playback tool with no annotations and no output schema, the description provides excellent completeness. It explains what the tool returns in detail, includes use cases, examples, behavioral features, and requirements. This compensates well for the lack of structured output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'token' parameter is fully described in the schema as 'Spotify access token for authentication'). The description adds no additional parameter information beyond what's in the schema, which is acceptable given the high schema coverage. Baseline 3 is appropriate when the schema does the heavy lifting.
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 with a specific verb ('Get real-time information') and resource ('currently playing in the user's Spotify session'). It distinguishes from sibling tools like 'get_recently_played' or 'get_track' by focusing on real-time current playback rather than historical data or specific track lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section explicitly lists when to use this tool (e.g., 'Display "Now Playing" information', 'Track listening history in real-time'), and the 'REQUIREMENTS' section specifies prerequisites (valid token with user-read-playback-state scope, active session). This provides clear guidance on when to use versus alternatives like 'get_recently_played' for past data.
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: authentication requirement ('Valid Spotify access token'), regional filtering capability, and return content details (e.g., popularity scores, preview URLs). However, it lacks explicit rate limit or pagination information, though the limit parameter hints at constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it is verbose. Some content (e.g., detailed return items) could be condensed, and the front-loaded purpose statement is followed by extensive lists rather than prioritized 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?
Given no annotations and no output schema, the description provides comprehensive context: purpose, usage, parameters, returns, and requirements. It covers authentication, regionalization, and output details adequately. However, it lacks explicit error handling or rate limit information, which would enhance completeness for a 3-param 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?
Schema description coverage is 67% (2 of 3 parameters described). The description adds value beyond the schema: it explains the purpose of the country parameter ('region-specific releases'), provides context for limit ('how many discoveries you want'), and clarifies token usage ('Spotify access token for authentication'). It doesn't fully compensate for the missing limit description but adds meaningful 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 purpose: 'Discover the latest album releases available on Spotify.' It specifies the resource (albums) and verb (discover latest releases), and distinguishes it from siblings like get_album (single album) or search_albums (search query-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through dedicated sections: 'USE CASES' lists specific scenarios (e.g., weekly discovery, region-specific updates), 'EXAMPLES' shows query patterns, and 'TIPS' advises on parameter usage (country, limit). It implicitly distinguishes from siblings by focusing on new releases rather than search or existing content.
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 of behavioral disclosure. It effectively describes what the tool does (removes tracks), return values (confirmation, updated count, list of removed tracks, errors, final state), and constraints (max 50 tracks per request, exact track ID matching). It also mentions authentication requirements (Spotify token with user-library-modify scope), which is crucial for a mutation tool. It lacks details on rate limits or error handling specifics, but covers core behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it is overly verbose. Sections like 'LIBRARY MAINTENANCE' and 'CURATION TIPS' contain redundant information already covered in 'USE CASES', and the multiple examples could be condensed. While front-loaded with purpose, it includes unnecessary elaboration that reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 2 parameters, the description provides substantial context: purpose, usage, returns, examples, requirements, and behavioral details. It covers authentication, constraints, and expected outcomes comprehensively. However, it lacks explicit error handling guidance or rate limit information, leaving minor gaps for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining parameter semantics in the 'REQUIREMENTS' section: it clarifies that 'trackIds' must match exactly and have a maximum of 50 per request, and that 'token' requires a specific Spotify scope (user-library-modify). This provides practical context beyond the schema's basic descriptions.
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 removes tracks from the user's personal library, specifying the action (remove) and resource (tracks from personal library). It distinguishes from sibling tools like 'remove_from_playlist' by focusing on the personal library rather than playlists, and from 'unsave_playlist' by targeting tracks instead of playlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through sections like 'USE CASES' (e.g., clean up library, remove accidental saves), 'LIBRARY MAINTENANCE' (e.g., keep collection current), and 'CURATION TIPS' (e.g., regular cleanup, bulk removals). It implicitly distinguishes from alternatives by focusing on personal library tracks rather than playlist operations or other Spotify actions.
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 full burden and does well by describing what the tool returns (ranked results, artist details, popularity scores, links) and requirements (Spotify token, meaningful keywords). It doesn't mention rate limits, pagination, or error handling, but provides substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, etc.) but is quite lengthy. Some sections like 'SEARCH STRATEGIES' could be more concise, and the front-loaded purpose statement is clear but followed by substantial detail that could be streamlined.
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 search tool with 3 parameters, no annotations, and no output schema, the description provides comprehensive context including return values, use cases, examples, search strategies, and requirements. The main gap is lack of explicit output format details, but the 'WHAT IT RETURNS' section provides good semantic understanding.
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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description compensates by providing extensive search strategies and examples that clarify how to use the 'query' parameter effectively. While it doesn't explicitly mention 'limit' parameter, the examples and strategies add significant semantic value beyond the 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 states the tool searches for artists using names, genres, or keywords, with the specific purpose of discovering new music and talent. It distinguishes itself from sibling tools like 'search_albums', 'search_tracks', and 'get_artist' by focusing exclusively on artist search rather than other entity types or direct retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through the 'USE CASES' section, listing five specific scenarios when to use this tool. It also distinguishes from alternatives by focusing on search rather than direct retrieval (e.g., 'get_artist' for known artists) and includes 'REQUIREMENTS' section specifying prerequisites like a valid Spotify access token.
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 of behavioral disclosure. It effectively describes what the tool does (search with filtering and ranking), what it returns (multi-type results with metadata), and requirements (access token, query length). It includes advanced features like typo correction and market filtering, but lacks details on rate limits, error handling, or pagination, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (e.g., USE CASES, WHAT IT RETURNS), but it is overly verbose with redundant details (e.g., extensive examples and strategies that could be condensed). While informative, some sentences like 'Real-time search result updates' don't earn their place for core tool understanding, reducing efficiency.
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 4 parameters, 50% schema coverage, no annotations, and no output schema, the description does a good job covering purpose, usage, and behavioral aspects. It explains returns and requirements thoroughly, but lacks output format details (e.g., structure of results) and error scenarios, making it slightly incomplete for full agent 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?
Schema description coverage is 50% (only 'token' and 'query' have descriptions). The description compensates by explaining 'type' through the 'SEARCH TYPES' section and implying 'limit' via examples like 'limit' in context, though not explicitly. It adds meaning beyond the schema by detailing search strategies and use cases, but doesn't fully document all parameters, resulting in a slight gap.
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 performs 'comprehensive music search across all Spotify content types with intelligent filtering and ranking,' specifying the verb (search), resource (music/Spotify content), and scope (all content types). It distinguishes from siblings like search_tracks, search_albums, etc., by emphasizing its multi-type capability, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through sections like 'USE CASES,' 'EXAMPLES,' and 'SEARCH STRATEGIES,' detailing when to use it (e.g., for universal discovery, partial information searches, or dynamic recommendations). It implicitly distinguishes from sibling tools by covering multiple content types, though it doesn't explicitly name alternatives; the comprehensive examples and strategies make the context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (ranked track results with specific metadata), search precision characteristics, and requirements (Spotify access token). It doesn't mention rate limits, error conditions, or authentication details beyond the token requirement, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use Cases, What It Returns, Examples, etc.), but it's quite lengthy with multiple emoji-labeled sections. While all content is relevant, it could be more concise. The front-loading is good with the purpose statement first, but the overall length reduces efficiency.
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 search tool with 3 parameters, no annotations, and no output schema, the description provides substantial context: clear purpose, usage guidelines, return value details, examples, search strategies, and requirements. It effectively compensates for the lack of structured metadata. The main gap is not explicitly describing the output format structure, though it lists what information is returned.
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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds significant value beyond the schema: it explains what constitutes a good query ('Search terms should be specific for best results'), provides numerous examples of query strategies, and contextualizes the search purpose. However, it doesn't provide additional details about the 'limit' parameter beyond what's in the 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 states the tool's purpose: 'Search specifically for individual tracks with targeted filtering for precise song discovery.' It uses specific verbs ('search', 'discover', 'find') and distinguishes this track-focused search from other search tools like search_albums, search_artists, and search_playlists among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. The 'Search Precision' section explains this is 'track-specific results without album/artist clutter' and 'optimized for individual song discovery,' distinguishing it from broader search tools. The 'Use Cases' section gives concrete scenarios like finding specific songs, discovering tracks by artists, and building track-focused experiences.
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 of behavioral disclosure. It effectively describes key behavioral traits: it's a mutation operation (implied by 'transfer'), preserves playback state (position, queue, settings), handles transitions with minimal interruption, and includes requirements like authentication scope and device availability. However, it doesn't mention potential side effects like rate limits or error handling details beyond 'any error details'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it's overly verbose with 8 sections including redundant marketing-like phrases ('Seamlessly', 'Perfect for', 'Great for'). Many sentences don't earn their place for pure tool selection, such as the 'SMART HANDOFFS' section which repeats use case concepts. It could be more concise while maintaining clarity.
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 3 parameters, no annotations, and no output schema, the description does a good job covering purpose, usage, behavior, and requirements. The 'WHAT IT RETURNS' section compensates for the missing output schema by detailing response content. However, it lacks explicit error scenarios or performance characteristics, leaving some gaps for a mutation tool with authentication needs.
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?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description doesn't explicitly discuss parameters in a dedicated section, but it provides contextual meaning: 'deviceId' is implied through examples and use cases, and 'play' is indirectly covered in 'TRANSFER FEATURES' ('Option to start playing immediately or stay paused'). This adds useful semantics beyond the schema, though not comprehensively for all 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 specific action ('transfer active playback from one device to another') and resource ('playback state'), distinguishing it from all sibling tools which handle different operations like searching, getting data, or controlling playback without transfer. The title 'Seamlessly transfer active playback...' provides a precise verb+resource combination that is unique in the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool through dedicated 'USE CASES' and 'SMART HANDOFFS' sections, listing scenarios like moving music between devices when changing locations. It also specifies 'REQUIREMENTS' that implicitly indicate when not to use it (e.g., without valid token or offline target device), though it doesn't name specific alternative tools from the sibling list.
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 and does so well. It discloses key behavioral traits: it's a destructive operation (removes/unfollows), requires specific authentication ('Valid Spotify access token with playlist-modify-public scope'), has limitations on playlist types, and describes what happens ('Doesn't delete the original playlist', 'You can re-follow anytime'). It doesn't mention rate limits or error handling beyond basic troubleshooting, but covers most critical aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with clear purpose, but includes extensive sections (e.g., 'MANAGEMENT TIPS', 'TROUBLESHOOTING') that, while helpful, add redundancy and length. Some information (e.g., 'Regular cleanup helps keep library organized') is not essential for tool selection. It could be more concise by focusing on core operational details.
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 no annotations, no output schema, and 2 parameters with full schema coverage, the description is largely complete. It covers purpose, usage, behavior, limitations, and requirements thoroughly. The main gap is the lack of output details (only general descriptions like 'Confirmation of successful playlist unfollow'), but with no output schema, this is a minor shortfall in an otherwise comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining parameter semantics in context: the 'token' requires 'playlist-modify-public scope', and 'playlistId' must be for a 'user-created playlist you follow'. This clarifies requirements beyond the schema's generic descriptions, though it doesn't detail format specifics like URI parsing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('remove', 'unfollow') and resource ('user-created playlist from your Spotify library'), distinguishing it from siblings like 'remove_from_playlist' (which removes tracks) and 'save_playlist' (which follows playlists). The title 'unsave_playlist' is directly explained as unfollowing a playlist, avoiding tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('Clean up library by unfollowing user-created playlists') and when not to use it ('Cannot unfollow Spotify's official/editorial playlists', 'Only works with user-created playlists'), with clear alternatives implied (e.g., use other tools for non-user-created playlists). The 'USE CASES' section provides specific scenarios, and 'LIMITATIONS' defines exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 and excels at it. The 'SKIP BEHAVIOR' section details specific rules (e.g., 'Restarts current track if more than 3 seconds have played', 'Goes to actual previous track if within first 3 seconds'), and the 'WHAT IT RETURNS' section explains output behavior, providing rich operational context beyond basic functionality.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, SKIP BEHAVIOR, REQUIREMENTS) that make information easy to find. While comprehensive, some sections like EXAMPLES could be more concise, but overall the structure enhances readability without excessive verbosity.
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 tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, behavioral rules, return information, examples, and requirements. The 'WHAT IT RETURNS' section effectively substitutes for an output schema by detailing what information the agent can expect back.
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%, providing complete parameter documentation. The description doesn't add any additional parameter semantics beyond what's already in the schema (token for authentication, deviceId optional). This meets the baseline expectation when schema coverage is comprehensive.
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 with specific verbs ('skip to the previous track' and 'restart the current track from the beginning'), distinguishing it from sibling tools like 'skip_to_next' and 'pause_player'. It precisely defines what the tool does in different scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides explicit guidance on when to use this tool (e.g., 'Go back to replay favorite parts of songs', 'Correct accidental skips to next track'), and the 'REQUIREMENTS' section clearly states prerequisites like 'Active playback session currently running' and 'Previous track must exist in queue or history', offering comprehensive usage context.
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 full burden and does well by disclosing authentication requirements ('Valid Spotify access token'), device requirements ('active Spotify device available'), market restrictions, and return information. It could improve by mentioning rate limits or error handling specifics, but covers most critical behavioral aspects.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, PLAYBACK OPTIONS, REQUIREMENTS) and every sentence adds value. It's appropriately detailed for a complex playback initiation tool without unnecessary verbosity.
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 4-parameter tool with no annotations and no output schema, the description provides comprehensive context including return values, examples, usage scenarios, and requirements. The only minor gap is not explicitly documenting all possible error conditions or response formats, but it covers most essential information.
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 only 50% schema description coverage (only 'token' and 'deviceId' have descriptions), the description compensates well by explaining 'contextUri' and 'trackUris' in the 'PLAYBACK OPTIONS' section, clarifying their purpose and usage. It adds meaningful context beyond what the sparse 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?
The description clearly states the tool's purpose with specific verbs ('initiate music playback') and resources ('tracks, albums, playlists, or artist collections'). It distinguishes this from sibling tools like 'pause_player', 'resume_player', or 'search_and_play_music' by focusing specifically on starting playback with various content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through the 'USE CASES' section with five specific scenarios, 'PLAYBACK OPTIONS' explaining parameter usage, and 'REQUIREMENTS' detailing prerequisites. It implicitly distinguishes from siblings by focusing on initiation rather than control (pause/resume), queue management, or search-and-play functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It details what the tool returns (confirmation, current volume, device info), how volume changes behave (instantly during playback, preserves for future sessions), and specific requirements (authentication scope, device availability).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it's quite lengthy with multiple bullet points that could be more streamlined. While informative, some redundancy exists (e.g., examples reiterate what the tool does).
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 mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, return values, parameter semantics, examples, behavioral details, and requirements - leaving no significant gaps for the agent to understand and invoke this tool correctly.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining the volume_percent parameter's meaning in the 'VOLUME CONTROL' section (0=complete silence, 100=maximum, range context) and providing practical examples that illustrate parameter usage.
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 with a specific verb ('Adjust') and resource ('volume level for the user's active Spotify device'), distinguishing it from all sibling tools which focus on playback control, content retrieval, or playlist management rather than volume adjustment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance through the 'USE CASES' section (e.g., dynamic adjustments, smart home automation) and 'REQUIREMENTS' section (valid token with specific scope, active device). It also distinguishes from siblings by focusing solely on volume control.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 and excels at it. The 'QUEUE BEHAVIOR' section details how tracks are ordered, when they play, and integration with shuffle/repeat settings. The 'WHAT IT RETURNS' section describes the response format, and 'REQUIREMENTS' covers authentication needs and constraints like market availability.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.) and front-loaded with the core purpose. While comprehensive, some sections could be more concise (e.g., USE CASES has 5 bullet points where 3 might suffice), but overall it's efficient with minimal redundancy.
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 3-parameter tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, return values, behavioral details, examples, and requirements - giving the agent everything needed to understand when and how to use this tool effectively.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of trackUri through examples ('spotify:track:4uLU6hMCjMI75M1A2tKUQC') and clarifying deviceId behavior ('uses active device if not specified') in the requirements section, though it doesn't explicitly map all 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 specific action ('Add a specific track to the user's playback queue') and distinguishes it from sibling tools like 'add_to_playlist' or 'create_playlist' by focusing on immediate/upcoming playback rather than playlist management. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides explicit guidance on when to use this tool (e.g., 'Queue up requested songs during parties', 'Add discovery tracks without interrupting current playlist'), and the 'REQUIREMENTS' section clearly states prerequisites like active playback session and valid access token. It implicitly distinguishes from playlist tools by focusing on temporary queue management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it explains what the tool does (resumes from paused state), what it returns (confirmation, track info), smart features (maintains settings, device flexibility), and requirements (token scope, session existence, device availability), covering mutation, authentication, and constraints.
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 well-structured with sections (USE CASES, WHAT IT RETURNS, etc.), but it is somewhat lengthy; every sentence adds value (e.g., clarifying returns, examples, requirements), though it could be more front-loaded by placing key behavioral info earlier.
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?
Given the tool's complexity (resuming playback with device handling), no annotations, 50% schema coverage, and no output schema, the description is highly complete: it covers purpose, usage, behavior, returns, examples, smart features, and requirements, providing all necessary context for an agent to invoke it correctly.
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?
Schema description coverage is 50% (only 'token' and 'deviceId' have descriptions), but the description compensates by explaining parameter roles implicitly: it mentions 'target device' aligning with 'deviceId', and the 'SMART RESUME' section implies how 'contextUri' and 'trackUris' might be used to maintain queue settings, adding context beyond the 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 states the tool's purpose with specific verbs ('resume paused playback', 'continue playing') and distinguishes it from siblings like 'pause_player', 'start_playback', and 'search_and_play_music' by focusing on resuming existing sessions rather than starting new ones or pausing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section provides explicit scenarios for when to use this tool (e.g., after interruptions, returning to apps), and the 'REQUIREMENTS' section specifies prerequisites (e.g., valid token, existing playback session), clearly differentiating it from alternatives like 'start_playback' which initiates new playback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. The 'SKIP BEHAVIOR' section details how skipping works with shuffle/repeat modes, and 'WHAT IT RETURNS' describes the response format. The 'REQUIREMENTS' section covers authentication needs and prerequisites.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.) but could be more concise. Some sections like 'EXAMPLES' and 'SKIP BEHAVIOR' contain redundant information that could be condensed while maintaining clarity. The front-loading is effective with the core purpose stated first.
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 mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, return values, behavioral details, examples, and requirements - giving the agent everything needed to understand when and how to use this tool effectively.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining authentication requirements ('Valid Spotify access token') in the REQUIREMENTS section, which provides context beyond the schema's parameter descriptions. However, it doesn't add significant additional parameter semantics beyond what the schema already documents well.
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 specific action ('Skip to the next track') and resource ('user's playback queue or playlist'), distinguishing it from siblings like 'skip_to_previous' and 'pause_player'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section explicitly lists multiple scenarios for when to use this tool, and the 'REQUIREMENTS' section clearly states prerequisites (active playback session, valid token, available next track). It also distinguishes from alternatives by focusing on next-track skipping specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 effectively describes what the tool returns (e.g., 'Ranked search results based on relevance', 'Album artwork and Spotify popularity metrics'), requirements ('Valid Spotify access token'), and search behavior ('Use quotes for exact phrase matching', 'Combine artist and album names'). This covers key operational aspects beyond basic functionality.
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 well-structured with clear sections (USE CASES, WHAT IT RETURNS, EXAMPLES, etc.), making it easy to scan. However, it is lengthy with multiple bullet points, which, while informative, could be more concise. Every sentence earns its place by adding value, but some redundancy exists (e.g., examples reiterate use cases).
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?
Given the tool's complexity (search functionality with 3 parameters), no annotations, and no output schema, the description is highly complete. It covers purpose, usage, behavioral details, parameter context, and output information comprehensively. The lack of output schema is mitigated by the 'WHAT IT RETURNS' section, ensuring the agent understands the response format.
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 description coverage is 67% (2 out of 3 parameters have descriptions), but the description compensates by adding significant value. It explains the 'query' parameter in detail through examples and search tips, clarifies the need for a 'token' in requirements, and implies usage of 'limit' through context like returning 'ranked search results'. This enhances understanding beyond the schema's minimal descriptions.
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: 'Search for albums using flexible keywords, artist names, or album titles to discover music.' It specifies the verb ('search'), resource ('albums'), and scope ('flexible keywords, artist names, or album titles'), distinguishing it from sibling tools like 'search_artists' or 'search_tracks' that target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through sections like 'USE CASES' (e.g., 'Finding albums when you only remember partial information'), 'EXAMPLES' (e.g., 'Search for albums by 'Pink Floyd''), and 'SEARCH TIPS' (e.g., 'Use quotes for exact phrase matching'). It implicitly distinguishes from alternatives by focusing on album-specific search, unlike broader tools like 'search_music'.
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-OAuth-MCP-server MCP server](https://glama.ai/mcp/servers/latiftplgu/Spotify-OAuth-MCP-server/badges/card.svg)](https://glama.ai/mcp/servers/latiftplgu/Spotify-OAuth-MCP-server)

Score Badge

Copy to your README.md:

[![Spotify-OAuth-MCP-server MCP server](https://glama.ai/mcp/servers/latiftplgu/Spotify-OAuth-MCP-server/badges/score.svg)](https://glama.ai/mcp/servers/latiftplgu/Spotify-OAuth-MCP-server)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/latiftplgu/Spotify-OAuth-MCP-server'

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