TIDAL Music MCP

by raydollete

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose. The only potential overlap (search_tidal vs batch_search_tidal) is resolved by the batch tool being explicitly for multiple queries. create_tidal_playlist and create_playlist_from_songs differ by input method (track IDs vs song descriptions). Download tools are separated by content type. No ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with lowercase underscores. Examples: add_tracks_to_playlist, delete_tidal_playlist, get_user_playlists. The pattern is uniform across all 16 tools, with no mixing of styles.
Tool Count5/5
16 tools is well-scoped for a music streaming service. It covers authentication, search, playlist management, recommendations, favorites, and downloads. Each tool serves a clear function without unnecessary bloat.
Completeness4/5
The tool set covers core CRUD for playlists (create, read, add tracks, delete), search, recommendations, favorites retrieval, and downloads. Missing are playlist update (title/description), track removal, and add/remove favorite tracks. These are minor gaps; the surface is largely complete for typical MCP interactions.
Average 4.4/5 across 16 of 16 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions error handling for authentication issues but does not disclose other behaviors like rate limits, data freshness, or that it is a read-only 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 contains redundancy, repeating 'Retrieves tracks from the user's TIDAL account favorites' and 'This function retrieves the user's favorite tracks from TIDAL.' It could be more concise by merging the initial statement and the Args/Returns section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema, no annotations), the description is fairly complete: it covers purpose, usage cues, parameter meaning, and return format. It does not mention pagination, but that is not critical for the tool's use.
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 coverage is 0% for the single parameter 'limit'. The description adds meaning by explaining the default value (20) and advises that it should be large enough unless specified otherwise, which compensates well for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves tracks from the user's TIDAL favorites using specific verbs and resource. It does not explicitly contrast with siblings like 'download_favorites', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries for when to use the tool, such as 'What are my favorite tracks?' and 'Show me my TIDAL favorites'. It lacks exclusions or alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral transparency. It correctly indicates this is a destructive action ('Deletes a TIDAL playlist') and mentions authentication. However, it omits details on error handling (e.g., what happens if the playlist doesn't exist) and any irreversibility beyond deletion. The processing steps are a nice touch but not comprehensive.
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 longer than necessary, with a list of example user requests that could be condensed. The 'When processing the results' section adds some structure but feels redundant. Overall, it is moderately concise but could be tightened 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 tool's simplicity (1 required parameter, no output schema), the description covers the core aspects: what the tool does, when to use it, authentication, and post-processing steps. It is sufficiently complete for a delete operation, though it could mention that the playlist must belong to the authenticated user.
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 coverage is 0% (only a title for playlist_id), so the description's explanation of the parameter ('The TIDAL ID of the playlist to delete (required)') adds essential meaning beyond the schema. This compensates for the lack of schema descriptions, making the parameter clear.
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 'Deletes a TIDAL playlist by its ID' and provides specific examples of user requests, making the purpose unambiguous. It distinctively focuses on deletion, differentiating it from sibling tools like create_tidal_playlist or add_tracks_to_playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage instructions ('USE THIS TOOL WHENEVER...') and lists common user requests, which is helpful. It also notes the authentication requirement. However, it lacks guidance on when not to use it (e.g., if the playlist is not owned by the user) or alternatives for related tasks like removing tracks.
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?
Describes sorting by last updated date and processing instructions, but lacks details on authentication, side effects, or error handling; no annotations to compensate.
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?
Contains redundant example list and processing instructions beyond the core description, making it slightly verbose for what it does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool, the description covers purpose, usage examples, and sorting behavior; missing only minor details like authentication requirement.
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?
No parameters, so schema coverage is 100%; description adds no parameter info, which is acceptable. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches the user's playlists from their TIDAL account') and distinguishes from sibling tools like create/delete playlist 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?
Provides explicit example queries and advises to use this tool for those cases, but does not mention when not to use or 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?
No annotations are provided, so the description carries full burden. It discloses that recommendations are based on seed tracks, uses default limits, and instructs not to include seed tracks in results. However, it does not mention any side effects or authorization needs beyond the tool's purpose.
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 (over 400 words) and includes extensive post-processing instructions for the AI (steps 1-10) that are not part of the tool's core definition. The essential purpose and parameters are buried among verbose guidance.
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 (seeds, filters, limits, and recommendation logic), the description is quite complete. It explains behavior when track_ids is empty, how limits work, and what the output contains. It could be improved by more explicitly stating the return 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?
Schema description coverage is 0%, but the description compensates by explaining each parameter in detail: track_ids (optional seeds), filter_criteria (string), limit_per_track (default 20, with rationale), and limit_from_favorite (default 20). It adds meaning beyond the schema's type and default values.
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 it recommends music tracks based on specified track IDs or the user's TIDAL favorites, and distinguishes from sibling tools by focusing on recommendations rather than search, playlists, or downloads.
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 explicitly lists when to use the tool with concrete examples (e.g., 'Music recommendations', 'What should I listen to?'). It does not explicitly state when not to use it, but the positive use cases are very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states that the tool creates a new playlist and adds tracks, and mentions authentication. But it does not disclose potential side effects (e.g., duplicate names), error conditions, rate limits, or whether the operation is reversible. More behavioral details could be provided.
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 bullet points and sections, but it is somewhat verbose, especially the naming convention guidance. The first sentence is clear, and the most critical information is front-loaded. It could be tightened without losing value.
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 (3 parameters, no output schema, no annotations), the description is remarkably complete. It covers purpose, usage guidelines, parameter meanings, authentication requirement, naming convention advice, and even post-processing steps including confirmation and URL inclusion. It leaves little ambiguity for an AI agent to select and invoke the 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 coverage is 0%, so the description must compensate. It explains that track_ids are 'TIDAL track IDs' and that description is optional with a default. However, it does not define constraints for the title parameter (e.g., length, allowed characters). The naming convention guidance is helpful but pertains more to usage than 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 starts with a clear verb and resource: 'Creates a new TIDAL playlist with the specified tracks.' It also lists specific user requests that trigger this tool, clearly distinguishing from sibling tools like add_tracks_to_playlist which adds to existing 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 explicit examples of when to use this tool ('USE THIS TOOL WHENEVER A USER ASKS FOR:') and mentions the prerequisite of TIDAL authentication. However, it does not explicitly state when not to use it or mention alternatives like add_tracks_to_playlist for adding to existing playlists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It indicates that the tool waits for authentication completion with a timeout and returns a dictionary. However, it lacks details on what happens on timeout, error conditions, or side effects, leaving some uncertainty.
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 very concise and well-structured, with the purpose front-loaded immediately. Every sentence is relevant and necessary, with no wasted words.
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 of authentication flows and the existence of 15 sibling tools, the description provides sufficient context: it explains the flow, return type, and parameter. The absence of an output schema is partially compensated by mentioning the return dictionary. A brief note on error/timeout behavior would improve 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?
Although the input schema coverage is 0%, the description includes an 'Args' section that explains the timeout parameter's meaning and default value. This adds semantic value beyond the schema, which only lists the parameter name and type.
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: 'Complete a pending TIDAL authentication.' It specifies the context (after tidal_login and user completes browser login), making it easily distinguishable from sibling tools like tidal_login.
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 explicitly tells when to use this tool: after tidal_login() and user completes browser login. It mentions the timeout parameter but does not provide explicit when-not-to-use instructions or alternatives, though the sibling tools are mostly unrelated operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It clarifies that duplicates are handled based on the allow_duplicates flag, but it does not mention error conditions (e.g., invalid playlist_id, authentication requirements) or confirm that it is a write operation. More detail would improve transparency.
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 front-loaded with purpose and includes structured sections (usage, parameters, results). However, it is slightly verbose, especially the processing instructions that could be condensed or moved to an output schema.
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 output schema, the description adequately describes the return value (dictionary with status and count). It covers the main behaviors but lacks details on error responses and edge cases, which would enhance completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains each parameter: playlist_id (required, obtainable via get_user_playlists), track_ids (list of TIDAL track IDs), and allow_duplicates (behavior when false). It adds context beyond the schema, though it could specify that track_ids items must be strings.
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 begins with a clear statement of the tool's function: 'Adds tracks to an existing TIDAL playlist.' It uses a specific verb ('adds') and resource ('existing TIDAL playlist'), and the purpose is distinct from sibling tools like create_tidal_playlist or delete_tidal_playlist.
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?
Explicitly lists example user requests that should trigger this tool ('Add this song to my playlist', etc.) and implies when not to use it (when the playlist does not already exist). This provides clear decision guidance.
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 fully explains pagination behavior, response structure, and the need to check total_available to fetch additional tracks. It does not cover authentication or rate limits, but as a read operation, the provided details are sufficient.
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, bullet points, and numbered lists. It is front-loaded with the core purpose but could be slightly more concise, especially the 'When processing the results' section which is useful but somewhat verbose.
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 (pagination, multiple parameters, no output schema), the description is highly complete. It covers prerequisites, pagination mechanics, response fields, and even post-processing steps. It leaves little ambiguity for an AI agent.
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 'Args' section in the description adds meaning beyond the input schema by explaining each parameter's purpose, default values, and constraints (e.g., limit max 500). This compensates for the 0% schema description coverage indicated by context signals.
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 'Retrieves tracks from a specified TIDAL playlist with pagination support' and provides extensive examples of user queries that map directly to this tool. It distinguishes itself from siblings like get_favorite_tracks and get_user_playlists by focusing on playlist 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 explicitly lists when to use the tool with example queries and mentions the prerequisite of obtaining playlist_id from get_user_playlists(). It does not explicitly state when not to use it, but the examples and context provide clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses return format (dictionary with grouped results and top_hit) and gives processing instructions. Does not explicitly state idempotency or safety, but as a search tool it is assumed read-only.
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?
Description is structured with clear sections (purpose, when to use, processing instructions, args, returns) and front-loaded. It is somewhat long but necessary given the lack of annotations and schema descriptions; every sentence adds 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?
No output schema, so description compensates by explaining return format and processing steps. Covers search across multiple content types with parameter details. Could mention pagination behavior, but limit parameter suffices. Overall complete for a search tool.
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?
Schema description coverage is 0%, but the description thoroughly explains each parameter: query with examples, search_type with explicit options ('track', 'album', 'artist', 'playlist', 'all'), and limit with default (50) and max (300). This adds significant 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?
Description clearly states 'Search TIDAL's catalog for tracks, albums, artists, and playlists.' It provides specific example user requests and distinguishes from sibling tools like batch_search_tidal, which handles multiple queries.
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?
Explicitly lists when to use the tool with concrete user requests ('USE THIS TOOL WHENEVER A USER ASKS FOR:'). Does not explicitly mention when not to use or alternatives, but the sibling context and the examples make usage 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, the description carries the full burden. It discloses the requirement for external tool installation and separate authentication, and mentions the file will be saved to tidal-dl-ng's configured location. However, it doesn't detail error messages or edge cases like network failures.
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 distinct sections (usage, prerequisites, processing results, args, returns). Though somewhat long, it is clear and organized. Minor redundancy could be trimmed.
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 output schema, the description mentions the return is a dictionary with status and messages. It covers prerequisites and typical user requests. For a download tool depending on an external tool, it provides sufficient context for successful use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds value by explaining that track_id is the TIDAL track ID and is a numeric string. This provides context beyond the raw schema definition.
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 it downloads a TIDAL track to local storage using tidal-dl-ng. It distinguishes from sibling tools like download_album and download_playlist by specifying it's for 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 explicitly provides usage scenarios with examples (e.g., 'Download this track', 'Save this song to my computer') and lists prerequisites (installation and separate authentication). This guides the agent on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the workflow (batch search, collect matches, create playlist), maximum 100 songs per request, and the return structure. However, it does not mention potential side effects (e.g., overwriting existing playlists) or required permissions. Still, it's fairly transparent about behavior.
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 (purpose, when-to-use, workflow, args, returns, example). It is slightly verbose but every part adds value. Front-loaded with the main verb and resource. Could trim minor redundancy but overall efficient.
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 has 3 parameters, no output schema, and no annotations, the description provides comprehensive context: return dictionary details (playlist, matched_songs, unmatched_songs, match_rate), workflow steps, example usage, and limitations (max 100 songs). It fully compensates for the lack of structured documentation.
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?
Schema coverage is 0% (no property descriptions in schema), but the description adds an 'Args' block detailing each parameter: title as 'Name for the new playlist', song_descriptions with examples and max 100, description as optional. This adds significant meaning beyond the bare 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 creates a TIDAL playlist by searching for songs and adding best matches. It distinguishes from siblings like 'create_tidal_playlist' (which likely creates empty playlists) and 'add_tracks_to_playlist' (which adds tracks by ID). The verb 'create' and resource 'playlist from songs' are specific.
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?
Explicit 'USE THIS TOOL WHEN:' section lists three scenarios (song names, descriptions, building from names). Implicitly tells when not to use (when track IDs are available). Also notes it's faster than alternatives like searching one-by-one then creating. Provides clear context.
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?
Discloses external dependency (tidal-dl-ng), separate authentication, potential download time, error handling guidance, and return format. No annotations exist, so the description fully bears this burden.
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?
Well-structured with sections for purpose, when to use, prerequisites, after-use steps, args, and returns. All sentences add value, though slightly verbose. Front-loaded with main action.
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 one parameter, no output schema, and low schema coverage, the description is remarkably thorough: covers purpose, prerequisites, usage, behavior, error handling, and return value. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal description (type string, title). The description's 'Args' section adds clear semantics: 'The TIDAL album ID to download (numeric string)', compensating for 0% 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?
Clearly states it downloads a TIDAL album to local storage using tidal-dl-ng. Provides specific user requests that should trigger this tool, distinguishing it from siblings like download_track or download_playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use the tool with example queries and important prerequisites (installation, authentication). Lacks explicit 'when not to use' but provides comprehensive 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?
Discloses external dependency (tidal-dl-ng), separate authentication, long download times, and file save location. No annotations provided, so description carries full burden. Minor omission: no mention of disk space or cancellation behavior.
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?
Well-structured with sections and bullet points, but slightly verbose with repeated examples. Front-loaded purpose and guidelines effectively.
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?
Covers installation, authentication, expected behavior, result handling, and time expectations. Adequate for a tool with external dependencies and no output schema.
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?
Single parameter (favorite_type) fully explained with values and effects. Schema coverage 0% but description adds complete semantics beyond the basic schema definition.
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 it downloads all favorites of a specific type from TIDAL using tidal-dl-ng. It distinguishes from sibling tools like download_album, download_playlist, and download_track, which operate on individual items.
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?
Explicitly lists user requests that should trigger this tool (e.g., 'Download all my favorite tracks'). Provides prerequisites and warnings, and mentions error handling steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses main behavior (returns auth URL, success if already authenticated) but omits details like URL expiration or error handling. Minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 5 sentences (including returns block), all sentences earn their place. Front-loaded with action verb 'Initiate'. No wasted words.
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 zero parameters and no output schema, the description is complete: explains purpose, manual flow, completion call, and return value.
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?
No parameters exist (0 params), so baseline is 4. Description adds meaning by explaining the tool's purpose and return value beyond the empty 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?
Description clearly states it initiates TIDAL authentication, returns an auth URL, and distinguishes from the sibling tool tidal_login_complete by specifying when to call that 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?
Explicitly tells when to use (initiate auth) and when not (already authenticated returns success). Also provides step-by-step guidance to call tidal_login_complete after manual login.
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?
No annotations exist, so description carries full burden. It discloses that download may take long, requires external setup, separate authentication, and explains return value (dictionary with status/messages). All behavioral aspects are covered.
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 (prerequisites, usage, processing), but is somewhat lengthy. Could be slightly more concise, yet every sentence adds value and it's front-loaded with purpose.
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 (external dependency, async download), the description is comprehensive: prerequisites, usage cues, error handling, output explanation, and reference to sibling tool. No output schema exists, but description explains return value adequately.
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?
Only one parameter (playlist_id). Schema only provides type/title, but description adds meaning: it's a TIDAL playlist ID/UUID and suggests using get_user_playlists to get it. This fully compensates for the 0% schema description 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 action ('Downloads a TIDAL playlist to local storage using tidal-dl-ng') and identifies the resource (playlist). It distinguishes from sibling tools like download_album and download_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?
Explicitly lists when to use (user asks to download, save) and provides prerequisites (installed tidal-dl-ng, separate authentication). Includes error handling steps and references sibling get_user_playlists for obtaining IDs.
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?
Discloses concurrency, 10-50x speedup, maximum 100 queries, and expected result structure including error handling. No annotations present, so description fully compensates.
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?
Well-organized with sections for overview, usage, processing steps, and parameter details. No redundant sentences; every sentence adds value.
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?
Despite no output schema, description fully explains return structure, how to interpret results, and error handling. Covers all necessary context for an AI agent to use the tool effectively.
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?
With 0% schema coverage, description extensively explains both parameters: queries can be strings or dicts with type options, limit_per_query with default and max, plus an example showing 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?
Clearly states it searches TIDAL for multiple items in a single request, explicitly contrasting with the less efficient search_tidal. Verb 'search' and resource 'TIDAL' are specific.
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?
Provides explicit 'USE THIS TOOL WHEN' list with concrete scenarios, and implies when not to use by comparing efficiency with sibling search_tidal.
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:

[![tidal-dl-mcp MCP server](https://glama.ai/mcp/servers/raydollete/tidal-dl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/raydollete/tidal-dl-mcp)

Score Badge

Copy to your README.md:

[![tidal-dl-mcp MCP server](https://glama.ai/mcp/servers/raydollete/tidal-dl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/raydollete/tidal-dl-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/raydollete/tidal-dl-mcp'

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