navidrome-mcp

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, but create_playlist vs create_smart_playlist and update_playlist vs commit_daylist could cause confusion. Descriptions help clarify boundaries, though an agent might occasionally select the wrong one.
Naming Consistency4/5
The majority follow a verb_noun pattern (list_, delete_, create_, update_), but a few depart with noun phrases like similar_tracks, listening_history, and daylist_context. The names are still readable and predictable, with no chaotic mixes.
Tool Count5/5
15 tools is at the upper edge of the ideal range, but each tool addresses a distinct facet of the library/playlist domain. The count feels justified and not bloated.
Completeness4/5
Playlist CRUD is well covered, including smart playlists. Minor gaps exist: no direct way to edit smart playlist rules, and no standalone track detail tool. However, search_tracks and update_playlist cover most needs.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: true. The description adds meaningful context: 'Permanently delete' reinforces irreversibility, and 'Does not touch the audio files' clarifies a key behavioral boundary. This goes beyond what the annotation alone conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the action and a crucial caveat. There is no filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers purpose and safety, and the destructiveHint annotation adds context. However, it omits guidance on parameter selection and the fact that both parameters are optional, which is a notable gap given the schema provides no descriptions and there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description makes no mention of the parameters 'name' and 'playlist_id.' The agent receives no guidance on which to use, whether they are alternatives, or which is required (especially since both are optional in the schema). The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Permanently delete a playlist.' It clearly distinguishes from sibling tools like update_playlist and get_playlist, and adds the clarifying statement 'Does not touch the audio files' to define the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a playlist_id from list_playlists) or explicitly say 'use when you want to remove a playlist.' The context of siblings is not leveraged to explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation; the description adds the detail that the full track list is returned and that lookup can be by id or name. It does not disclose the existence of the limit parameter, which may implicitly restrict the 'full' list, nor does it describe return structure or pagination, so behavioral transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the resource and selection method. It is free of fluff and front-loads the core action, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description covers the primary use case and the id/name selection mechanism. However, the limit parameter is not mentioned, and there is no guidance on how the result set behaves (e.g., default limit, pagination), leaving a notable gap given the schema provides no parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that name and playlist_id are alternative selectors, but it ignores the limit parameter entirely. Given three undocumented parameters and the need to explain all, this partial coverage is insufficient.
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 the full track list of a single playlist, with explicit selection by id or name. It distinguishes itself from siblings like list_playlists (which lists playlists) and search_tracks (which searches tracks globally), 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool when you need a playlist's tracks and know the playlist's id or name. However, there is no explicit comparison to alternatives such as describe_library or list_playlists, nor any 'when not to use' guidance, leaving room for confusion in selecting among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the creation action without disclosing permissions, side effects, input validation, or return value. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It earns its place by providing the core action and a sourcing hint without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no annotations and no output schema, the description gives enough to initiate a basic creation. However, it omits behavioral details like return object and optional parameter effects, making it partially incomplete for an agent that needs full invocation confidence.
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 only 25%, so the description must compensate. It clarifies that track_ids is an explicit list and suggests search_tracks for sourcing, adding value for the primary parameter. However, it does not explain public or comment parameters beyond the schema, leaving gaps.
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 playlist from an explicit list of track IDs, which distinguishes it from the sibling create_smart_playlist. It also references search_tracks for sourcing, making the purpose unmistakable.
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 directs users to search_tracks to source track IDs, providing a clear workflow. It implies use when you have specific track IDs, contrasting with smart playlists, but does not explicitly list when-not-to-use cases or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two modes (replace vs append) and their intended use, but it does not describe side effects such as whether unspecified fields are preserved, permissions required, or what happens with missing track_ids. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the actions in the first sentence and provides a rationale in the second, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters, no output schema, and no annotations, the description is not fully complete. It covers the primary use cases but omits details like the relationship between name and playlist_id, the effect of public, and whether at least one field must be provided. However, the core behavior is clear enough for many agents.
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 only 29%, so the description must add meaning for the other parameters. It does explain the roles of mode, track_ids, new_name, and comment through the action phrases, but playlist_id and public are left undocumented. The description partially compensates for the schema gaps but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs: 'Rename a playlist, change its description, and/or replace or append its tracks.' It also provides a use case ('refresh a rolling playlist in place'), which distinguishes it from sibling tools like create_playlist or delete_playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use replace mode ('Replacing is the normal way to refresh a rolling playlist in place'), but it does not explicitly compare this tool to alternatives or state when not to use it. Sibling differentiation is implied by the purpose, but no direct exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the one-time permanent caching, the scope ('every track'), and the check-vs-run modes, plus why it cannot rely on existing metadata. However, it doesn't state the return format or authorization requirements, and the mutation is not explicitly flagged as a write, though 'cached permanently' implies persistent side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs; the first states the core purpose and outputs, the second provides rationale and persistence behavior. Every sentence adds value, though the first sentence is long and packed with attributes, making it slightly dense.
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 no output schema, the description explains the tool's role, prerequisites, caching, and the two modes (run/check), which covers the key behavior. It doesn't specify what a successful run returns (e.g., coverage counts), but the schema's status_only parameter hints at that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description reinforces the semantics by mentioning 'check' for status_only and 'trial run' for limit, but adds no new parameter-specific details 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 identifies the action ('Run (or check)') and the resource ('one-time pass that gives EVERY track a mood'), enumerating the specific mood attributes. It distinguishes from sibling tools by explaining it enables library-wide mood search, unlike playlist-scoped capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use: to enable mood search across the whole library, and explains why existing metadata is insufficient (genres are coarse, BPM/ReplayGain/MusicBrainz IDs under 3%). It doesn't explicitly name alternatives but implicitly differentiates from playlist-only operations and mentions the caching behavior for 'runs once'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read, and the description adds useful behavioral context by revealing the underlying similarity sources (Navidrome agents, Last.fm/Deezer/ListenBrainz, and co-occurrence in the user's own playlists) and the library restriction. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value. The description front-loads the core action and then provides necessary context on sources and constraints without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description doesn't specify the response structure (e.g., what fields are returned for each track). It clarifies that results are library-only but leaves the return format implicit, which is a moderate gap 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?
Schema description coverage is 75%, so the schema handles most parameter meaning. The description reinforces that 'track_ids' and 'artists' serve as seeds, but it doesn't clarify the undocumented 'limit' parameter or add meaning 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 uses a specific verb ('Expand') and identifies the resource ('seed tracks or artists') with clear scope ('Results are restricted to what is actually in the library'). It distinguishes this from siblings like search_tracks by explaining its similarity/co-occurrence mechanism.
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 conveys clear context: use this tool when you have seed tracks/artists and want library-restricted recommendations. It doesn't explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to decide.
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?
Annotations only provide readOnlyHint: true, so the description carries the burden of explaining behavior. It does so richly: it discloses the computed mood lift metric, historical dominance data, and the purpose of recent daylist titles. This goes well beyond the annotation, though it does not cover edge cases or error 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 a single, front-loaded sentence beginning with 'Everything needed...'. It is dense but contains no fluff, and each clause earns its place. The long list-style structure is slightly run-on but 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?
With no output schema, the description compensates by fully enumerating the returned context: time/part of day, mood lifts, artists/genres/tags, recent listens, and recent daylist titles. Combined with complete schema coverage for the two optional parameters, it is thoroughly complete for a read-only context 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 coverage is 100% with both parameters (hour_of_day, recent_runs) already described. The description adds no new parameter syntax or format details; it only implicitly relates them to the daylist generation workflow. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get daylist context'. It enumerates the exact contents (local time, part of day, mood lifts, artists/genres/tags, recent listens, recent daylist titles), making it easy for an agent to understand what the tool provides and how it differs from siblings like get_vibe_profile or listening_history.
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 says 'Everything needed to generate this hour's daylist', which gives clear context for when to use this tool. It does not explicitly name alternative tools or exclusion criteria, but the purpose is well-scoped relative to the listed 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?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds value by disclosing the output composition (artists, genres, tags, etc.), which is behavioral context beyond the annotation. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded, and every phrase earns its place. It efficiently conveys purpose, scope, and usage direction without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description effectively enumerates the return components, giving the agent a solid mental model of the result. It does not cover error handling or edge cases, but for a read-only profiling tool the provided information is nearly 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?
Schema description coverage is 100%, so the schema fully documents 'vibe' and 'sample' with examples and defaults. The description adds no extra parameter meaning beyond what the schema provides, earning the 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 profiles a user's mood playlist by listing its composition: top artists, genres, tags, era, tempo, play time, and representative tracks. It distinguishes from siblings like get_playlist by emphasizing 'mood playlist' and grounding abstract mood requests in the user's library.
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 a clear use case: 'Use this to ground an abstract mood request in what that word means in HIS library.' This tells the agent when to apply the tool. It does not explicitly mention alternatives or exclusions, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares a safe read operation. The description adds value by explaining the content of the response—it differentiates curated mood playlists and smart playlists—which is helpful context beyond the annotation. However, it does not disclose details like return structure or any potential filtering or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and the key distinguishing feature of its output. There is no waste or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-all tool with no parameters and no output schema, the description is mostly complete: it states the scope (all playlists) and the added value (type distinction). It could be more explicit about the return format, but given the lack of parameters and the simplicity of the operation, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description does not need to add parameter information.
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 lists all playlists in Navidrome and further specifies the distinction between curated mood playlists and smart (self-updating) playlists. This goes beyond just repeating the name and distinguishes it from sibling tools like get_playlist and create_playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing all playlists, but it does not explicitly state when to use this versus get_playlist for a single playlist or other alternatives. The context 'All playlists' gives a clear scope, but no exclusions or alternative tool references are provided.
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, but description discloses behavior well: full library pull (~20s), incremental listens, and cache semantics. It doesn't state side effects like network dependency or potential cache invalidation, but is reasonably transparent for a cache refresh.
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?
Three focused sentences: action, behavior, when-to-use. No wasted words; front-loads the verb.
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?
Covers purpose, timing, and usage trigger. Missing explicit mapping of 'and/or' sources to scope, but output schema is absent and the tool is simple, so it's largely 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?
Schema covers 100% of parameters with descriptions. Description adds context about the pull behavior (full vs incremental) that maps to scope/full_listens, but doesn't explicitly link parameters to behavior, so marginal value beyond 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?
Uses specific verb 're-sync' and identifies resources (Navidrome, ListenBrainz). Clearly distinguishes from sibling tools that manage playlists or query data; this tool maintains a local cache.
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 condition: 'Call this if the library changed and results look stale.' While alternatives aren't named, it clearly places this tool as the refresh mechanism for all read-oriented 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 readOnlyHint=true, the safety profile is already known. The description adds valuable behavioral context: the whole-library scope, that every filter composes, and the critical distinction that 'vibes' only matches ~3,800 curated tracks while mood fields cover all 9,000+. It also explains the mood_vibes prediction logic. This goes beyond the annotation.
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 dense but efficient. Two well-structured sentences cover the full scope and a crucial usage warning. The first sentence enumerates filter families without fluff; the second directly addresses a common misuse. It earns its length given the tool's complexity.
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?
Despite lacking an output schema and having 55 parameters, the description provides a strong conceptual overview and key operational details (mood vs vibes, whole-library scope, compound filtering). It doesn't mention pagination or return structure, but those are likely implicit given the filter list. It is adequate for an agent to select and invoke 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 47%, so the description must compensate. It groups all 55 parameters into meaningful categories (year/date ranges, recency, mood axes, descriptors, vibe membership, tags, duration, time-of-day, diversity caps, affinity ranking). It adds semantic depth by explaining how mood-related filters work differently from vibes, and clarifies max_per_artist usage. This is more than 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 it is 'The main query tool, over the WHOLE library' with a comprehensive list of filter categories. It distinguishes itself from siblings by emphasizing its primary search role and explicitly contrasting 'vibes' vs 'mood_vibes' to guide usage. This is a specific verb+resource+scope with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance for mood requests: 'prefer mood_vibes / moods / the axis ranges over vibes' and explains why, which functions as a when-to-use within the tool. It also establishes itself as the main query tool. However, it does not mention when to use sibling tools like similar_tracks or listening_history, so it lacks full alternative routing.
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?
Annotations only declare readOnlyHint=true, and the description adds meaningful context about the scope and content returned (size, distributions, curated playlists, tag vocabulary, history coverage). It provides useful behavioral disclosure for a read-only overview tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that begins with the core purpose, enumerates key outputs, and ends with actionable usage guidance. 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?
For a no-parameter read-only orientation tool, the description fully covers the returned content and when to use it. No output schema is needed given the clear narrative enumeration of results.
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?
Tool has zero parameters, so no parameter documentation is needed. Baseline 4 is appropriate because the description fully explains what information the tool provides without needing to describe inputs.
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 the tool provides an orientation for the entire music library, listing specific outputs (size, distributions, playlists, tags, history). It distinguishes itself from siblings by framing itself as the first call when library contents are unknown.
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 instructs to 'Call this FIRST' when building a playlist without prior library knowledge, giving a clear trigger condition. It does not name specific alternatives or when-not-to-use, but the context is sufficiently 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?
Annotations declare readOnlyHint=true, so no destructive behavior is expected. The description adds valuable context beyond the annotation by explaining the data source limitation (Navidrome keeps only play count and last-played), which helps the agent judge the tool's unique value. It does not disclose return format, but the read-only nature and enumeration of modes reduce the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. The first sentence lists the full scope of analyses in a compact list; the second sentence adds a crucial differentiator (only timestamped source). It is front-loaded with the main purpose and immediately useful.
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 no output schema, moderate parameter count, and read-only annotation, the description is sufficiently complete. It explains what the tool offers, why it exists, and the key constraint (only timestamped history). The mode enumeration covers the input schema's required parameter, and the context around Navidrome's limitation completes the picture.
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 75% (days, mode, hour_of_day described; limit has min/max). The description enriches the enum values by grouping them into meaningful categories (recent, top, habits, trends, rediscover), which helps an agent select the correct mode. It does not add detail for limit, but the schema already provides constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and resource ('ListenBrainz history'), and enumerates the distinct analyses: recent plays, top artists/tracks, hour-of-day/weekday habits, trends, and rediscovery. It also differentiates from siblings by noting it is the only source of timestamped history, while Navidrome retains only play count and last-played time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever timestamped listening history is needed, since it is the only source. It does not explicitly name alternatives or provide 'when-not' guidance, but the contrast with Navidrome's limited data provides strong contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that Navidrome continuously re-evaluates rules, so playlists stay current without regeneration. It also reveals a key limitation: rules operate only on Navidrome's own fields, not ListenBrainz or Last.fm. With no annotations provided, this carries the full burden well, though it omits return values or error 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 dense but well-structured, opening with a clear purpose, then a concrete example, followed by operator/field lists and a limitations note. It is long, but every section earns its place given the complexity of the rules parameter.
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 complex nested rules object and no annotations/output schema, the description covers the critical aspects: rule syntax, operators, fields, and unsupported data. It could add what the API returns or error scenarios, but it is largely complete for invoking the tool correctly.
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 description provides an extensive explanation of the rules parameter, including a JSON example, a list of all operators, combinators (all/any), nesting, and available fields. This goes far beyond the schema's generic 'criteria object' description and fully compensates for the low schema coverage of other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Create a playlist defined by RULES rather than a fixed track list', distinguishing it from the sibling create_playlist. It also provides a concrete use case ('90s rock I haven't played in a year') and emphasizes the self-updating behavior.
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?
It explicitly positions the tool for standing/self-updating playlists with an example, and explicitly directs users to search_tracks plus create_playlist when ListenBrainz/Last.fm fields are needed. The contrast with fixed track lists is clear, giving both when-to-use and when-not-to-use 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?
With no annotations provided, the description carries full burden and delivers: it discloses the multi-step side effects (replace, rename, set description, record run) and the first-use creation behavior. It also explains the purpose of recording the run (avoid future repeats), which goes beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the first enumerating all core actions and the second addressing first-use creation. Every word earns its place, and the structure front-loads the main 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?
For a complex multi-step tool with no output schema and no annotations, the description is remarkably complete: it explains the atomic nature, the specific operations, the run recording, and first-time behavior. No critical gaps are evident for the intended use case.
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 covers two of three parameters with descriptions, and the tool description maps each parameter to its action (track_ids→tracks, title→new title, description→description). This adds meaningful context, especially for track_ids which lacks a schema description, supporting a score above the 3 baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: writes the daylist in one atomic step, replacing tracks, renaming, setting description, and recording the run. It uses a specific verb ('write') and resource ('daylist'), and distinguishes itself from generic create_playlist/update_playlist by describing the combined operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when publishing the daylist as a single atomic operation. It does not explicitly contrast with sibling tools like update_playlist, but the specialized wording implies this is the dedicated tool for daylist commits, making the usage context clear.
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:

[![navidrome-mcp MCP server](https://glama.ai/mcp/servers/312-dev/navidrome-mcp/badges/card.svg)](https://glama.ai/mcp/servers/312-dev/navidrome-mcp)

Score Badge

Copy to your README.md:

[![navidrome-mcp MCP server](https://glama.ai/mcp/servers/312-dev/navidrome-mcp/badges/score.svg)](https://glama.ai/mcp/servers/312-dev/navidrome-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/312-dev/navidrome-mcp'

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