lms-mcp

by eggs-gd

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct function (search, playback, queue editing, volume, etc.), and raw_command is clearly an escape hatch. Minor overlap exists between play_music's 'insert/add' modes and queue_edit's queue manipulation, but the descriptions make the boundary clear.
Naming Consistency4/5
Most tools follow a consistent snake_case verb_noun pattern like search_library, set_volume, and show_queue. A few exceptions such as raw_command, seek, and now_playing break the pattern slightly but remain readable and predictable.
Tool Count5/5
Twelve tools is within the ideal range for a media server control surface. Each tool addresses a core playback or queue function without unnecessary duplication.
Completeness5/5
The set covers the full playback lifecycle: discovering content, controlling transport, managing the queue, adjusting volume/seek/repeat/shuffle/power, and querying status. The raw_command escape hatch also covers edge operations missing from the curated surface.
Average 3.5/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It reveals that the tool mutates the queue and implies that clear is destructive, but it does not mention irreversibility, side effects, permissions, or what happens during move and jump operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the resource and lists all operations with no filler. It is efficiently structured, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too sparse to fully equip an agent. It does not specify which parameters are required for each action (e.g., clear needs only action, remove needs index, move needs index and toIndex) or what response to expect.
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 only 25%, so the description must compensate for the undocumented parameters. It adds meaning by linking actions to index usage (remove by index, jump to an index), but it leaves exact parameter combinations per action and the role of toIndex implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the queue) and enumerates four concrete edit operations: clear, remove, move, and jump. It is clear about what the tool does, though it does not explicitly differentiate from sibling tools like show_queue or playback_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use queue_edit versus alternatives such as show_queue or playback_control, and it offers no exclusions or prerequisites. The listed operations only imply a use case rather than explicitly routing an agent to the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the output is a state change (on/off) but does not disclose edge cases like whether players are discoverable, whether power state toggles or forces state, or any side effects such as stopping playback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that fully conveys the core action without wasted words. It is perfectly sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and 2 parameters, the description is adequate but incomplete. It does not describe return values, error cases, or interaction with other player states, which an agent might need when deciding whether powering off is safe or how to verify success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little beyond the schema, which already documents 'player' with a useful description. However, the required 'on' boolean has no description in the schema, and the tool description does not clarify its meaning beyond the title, so 50% coverage is only partially compensated.
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 'Turn a player on or off' clearly states a specific verb and resource, making the tool's purpose immediately understandable. It distinguishes from siblings like play_music or queue_edit by focusing on the binary power state of a player, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_repeat_shuffle or play_music. The description does not mention prerequisites like needing to know the player's current state or how this relates to other player controls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether omitting a parameter preserves the current setting, whether the change is immediate/persistent, or what happens if the player is invalid. The description only names the action without exposing side effects or state-change semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and target resources. Every phrase ('off/one/all', 'off/songs/albums', 'and/or') contributes essential information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description leaves important behavior unstated, such as defaults when only one parameter is supplied and whether both parameters can be applied together. An agent could guess the basic call, but the description is not fully self-sufficient.
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 only 33%, with repeat and shuffle having no schema descriptions beyond their enums. The description lists the enum values but does not explain what 'one', 'all', 'songs', or 'albums' mean behaviorally, so it only minimally compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with the imperative 'Set' and names the two specific resources affected: repeat and shuffle for a player, including valid modes. This clearly distinguishes it from sibling tools like set_volume or set_power, which control different player state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as playback_control, or when it should not be used. The intended use is only implied by the tool name and description; no context, exclusions, or alternative recommendations are provided.
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 of behavioral disclosure. It does not mention prerequisites like needing an active player, what 'toggle' actually toggles, side effects, or failure behavior. The description simply restates the action list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the operation type front-loaded and the action list immediately following. Every word contributes, with no filler or redundant explanation.
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 two-parameter tool, the description plus schema adequately defines the core call mechanics. However, the lack of annotations and absence of usage boundaries around player eligibility and the overlap with play_music leave some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some context by framing the actions as transport controls, but mostly repeats the enum values already present in the schema. The 'player' parameter is already documented in the schema, so the description provides minimal additional semantic value beyond the structured data.
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 ('Control transport') and explicitly enumerates all supported actions: play, pause, toggle, stop, next, and previous. This makes the tool's purpose unambiguous and distinguishes it from siblings like play_music or seek.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. Since play_music also includes a 'play' action, the boundary between playback_control and play_music is not addressed, and no exclusions or preferred contexts are mentioned.
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 of behavioral disclosure. It only states that it runs an arbitrary command, with no mention of side effects, destructive potential, permissions, rate limits, or return format. The 'escape hatch' wording hints at risk, but without explicit disclosure an agent cannot anticipate consequences.
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?
At roughly two sentences plus an example, it is appropriately sized and front-loaded with the high-level purpose. The doc URL and example earn their place. It could be more structured with explicit guidance on when to use it, but it is not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw escape-hatch tool with no annotations and no output schema, the description does not provide enough context: no return/error semantics, no side-effect warning, no guidance on auth or server target. The doc URL helps but shifts the burden to the agent to go read external docs.
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 50%, and the description adds meaningful context for the command parameter by providing an example array. It does not explain the player parameter beyond the schema, nor how server-scoped vs player-scoped commands interact. The example is helpful but does not fully compensate for the uncovered 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 states a specific verb ('run') and a specific resource: an arbitrary LMS CLI command. It is clearly an escape hatch, distinct from purpose-built tools, and provides a concrete example command and a documentation URL. The purpose is unambiguous and distinguishes it from siblings that would handle specific operations.
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 phrase 'Escape hatch' implies use when no dedicated tool covers the need, but there is no explicit when-not-to-use or named sibling alternative. The documentation URL grounds usage, and the example clarifies command structure, but the description relies on inference that dedicated tools should be preferred and does not mention edge cases like authentication or server selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' and 'current' imply a non-mutating, state-reading operation, which is useful. However, it does not disclose truncation/limit behavior, output shape, or whether the queue state is session-specific.
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 short sentence that front-loads the action and object. Every word contributes; there is no filler or redundant restating of the tool name.
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?
This is a simple tool with two optional parameters and no output schema, so the one-line description is close to adequate. However, it misses the semantic role of limit and gives no hint about the returned queue structure, leaving an agent to infer important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; the limit parameter has no semantic description in the schema, and the tool description does not explain its effect (e.g., truncating the returned queue). The description only loosely reinforces the player parameter already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') with a clear resource ('current play queue (playlist)') and target ('for a player'). This cleanly separates it from siblings like queue_edit (editing) and now_playing (current track).
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 such as now_playing or queue_edit. The description implies a read-only queue view but does not provide explicit selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly signals a read-only query operation ('Show') and discloses what data will be surfaced: current track, playback mode, volume, and queue position. It does not describe output formatting or error behavior, but for a simple status tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that names the tool's purpose and the key output fields without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description adequately names the output fields and the read-only action. It does not mention alternatives or edge cases, but those are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'player,' is already fully described in the schema with its default behavior (MAC address, exact name, or default player). The description adds no extra parameter semantics, so the baseline 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and names a clear resource: the current playback state of a player, including track, mode, volume, and queue position. It is informative enough to distinguish this from control tools like playback_control or set_volume, though it does not explicitly name an alternative like show_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings such as show_queue, playback_control, or set_volume. The read-only nature is implied by 'Show,' but there is no explicit condition, context, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that seeking is relative to the track start, but does not disclose what happens if seconds exceeds the track length, how seeking interacts with play/pause state, or whether any state change is reported back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the essential behavior without redundancy. It is appropriately concise and 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?
This is a simple tool, so the description is almost adequate, but it does not mention return values, error handling, or what occurs when the seek position is invalid or when no track is active. Agents will have to infer these behaviors from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the required seconds parameter by defining it as 'seconds from start' in the current track. The optional player parameter is already documented in the schema, so both parameters end up with adequate meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Seek), identifies the resource (current track), and clarifies the unit of the position (seconds from start). This makes it easy to distinguish from sibling tools like play_music or now_playing, and even from the broader playback_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the agent needs to move to a specific position in the current track. However, it gives no explicit guidance about when not to use it, nor does it point to alternatives like playback_control for related playback actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of disclosing side effects. It clearly explains that 'load' replaces the queue and plays, 'add' appends, and 'insert' plays next, which are key behavioral traits. It stops short of describing return values or error handling, but the core state-changing behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The main action and two input types are front-loaded, and the second sentence efficiently maps all three enum values to their concrete behaviors. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 optional parameters, no output schema, and no annotations, yet the description avoids explaining the id fields, player selection, or mutual-exclusion rules. It explains the core playback modes but leaves an agent guessing about how to construct a valid request, especially because 'library id' could map to albumId, artistId, trackId, genreId, or playlistId.
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 13%, so the description must compensate. It adds meaning to the 'mode' enum and clarifies that the various id fields are library ids. However, it does not explain which parameter combinations are valid (e.g., whether ids are mutually exclusive, whether 'url' can be combined with ids, or the role of 'player'), leaving significant ambiguity for several of the 8 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 loads or queues music, identifies two input sources (library id from search_library and direct URL), and explains playback behavior for each mode. This makes its purpose specific and distinguishes it from search-focused siblings like search_library and queue-edit operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: after searching the library or when you have a direct URL. It also explains what each mode does, which helps select the correct mode. However, it does not explicitly compare against alternative siblings like queue_edit or playback_control, so exclusion guidance is weak.
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 burden. It discloses the search scope (music library) and return types, plus the important integration with play_music. However, it does not disclose safety (e.g., read-only), result limits, pagination, or ordering, which would be beneficial for a search 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?
Two sentences with no filler. The action and return value are front-loaded, and the note about play_music integration adds valuable context 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 search tool with 2 parameters and no output schema, the description covers the core function. However, it omits resultformat distinctsion (e.g., how artists vs albums are structured) and any behavior around empty results or limit constraints, making it adequate but not fully 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 0%, so the description is the only source of parameter meaning. It clarifies that the query returns matching items and the ids are for play_music, but it does not explicitly explain the 'limit' parameter's behavior or its relationship between query and limit. Baseline is 3 since descriptions provides some semantics 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?
States the verb 'Search' with a specific resource ('the music library') and lists what it returns: 'matching artists, albums and tracks'. Importantly, it mentions the ids are used by play_music, distinguishing it from that sibling tool. The purpose is 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 implies this tool is for finding items before playing them, noting ids are 'used by play_music', giving clear context. However, it does not explicitly state when not to use it or mention alternatives like queue_edit, leaving some inference.
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 of disclosing behavior. 'List' and 'known to the server' make clear this is a read-only server query, and 'their state' indicates what is returned. However, it does not define what 'state' includes or whether disconnected/disababled players are listed, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The core action and scope are front-loaded, and every word 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?
For a zero-parameter tool with no output schema, the description is largely sufficient: it states what is listed (players) and what is returned (state). It does not specify the return structure or fields of 'state', but an agent can still invoke the tool and inspect the response without ambiguity.
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 schema description coverage is trivially 100%. With 0 params, the baseline is 4, and the description does not need to add parameter-level meaning. No parameter information is missing.
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 ('List') and identifies the exact resource ('Squeezebox / squeezelite players known to the server') plus what is returned ('their state'). This clearly distinguishes it from sibling tools like show_queue, now_playing, and playback_control, which focus on queues, current tracks, and playback actions.
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 discovering all players and their current state, which is a reasonable usage context. However, it does not explicitly state when to prefer this over sibling tools or mention any alternatives/exclusions. For a simple zero-parameter listing tool this is a minor gap rather than a serious one.
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 explaining behavior. It clearly communicates the mutating action and the two volume input styles, but it does not disclose potential side effects, clamping behavior for relative changes that exceed 0-100, error handling, or what happens if no player is specified. These are useful context gaps for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core operation and then immediately gives the two accepted value formats, which is exactly the information an agent needs without extra 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?
For a simple volume setter, the description plus schema covers the essential information: what the tool does, the valid volume forms, and the optional player target. It does not specify the return value or error behavior, but the absence of an output schema and the tool's simplicity make the current definition reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is about 50%: the 'player' parameter is described in the schema, but 'volume' is not. The description adds the human-readable meaning for volume, explaining that numeric values are absolute and string values are relative changes. This compensates for the schema gap and clarifies the intent of the pattern.
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 ('Set') and the target resource ('volume'), and specifies the allowed forms: absolute 0-100 or relative changes like +5/-10. This makes it easy to distinguish from sibling tools such as seek, set_power, or play_music, which address different controls.
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 volume adjustment, but it never explicitly says when to use it versus alternatives or lists exclusions. An agent can infer the use case from the name and description, but there is no direct guidance on when not to use it or when another tool would be more appropriate.
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

lms-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![lms-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/eggs-gd/lms-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eggs-gd/lms-mcp)

Score Badge

Copy to your README.md:

[![lms-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/eggs-gd/lms-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eggs-gd/lms-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/eggs-gd/lms-mcp'

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