Apple Music MCP

by Zheng-Kun

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: plan lifecycle, library browsing, playback control, and health checks. The plan-related tools are differentiated by their role (create, read, cancel, apply, list, undo), and there is no ambiguity between similar names.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern prefixed with music_ (e.g., get_playlist, list_playlists, control_playback). The only slight deviation is music_health, but it's a conventional health-check noun and does not disrupt the overall pattern.
Tool Count4/5
18 tools is slightly above the typical 3–15 range, but the count is justified by the domain's breadth (library, playback, change planning, and system health). Each tool serves a distinct function, and there is no redundancy or bloat.
Completeness5/5
The tool set covers the full lifecycle: library retrieval and search, playlist management, playback control and options, change planning with approval and undo, and audit history. No critical operations are missing for a comprehensive Apple Music server.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 2.7/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?
The annotations are all false, so they provide no positive safety or idempotency context. The description fails to disclose that actions like pause, stop, or seek alter playback state, whether playing a track or playlist interrupts current playback, or what the output response contains. It does not contradict annotations, but it adds minimal behavioral insight.
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 with no filler words. It efficiently communicates the core purpose, though it sacrifices necessary detail for brevity. It is concise, but not at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters (one required, multiple nullable) and an output schema, this description is incomplete. It does not explain how action interacts with track_id/playlist_id, what happens when no ID is supplied, or how position_seconds applies to seek. The surrounding sibling context and annotations do not fill this gap.
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 for the schema's lack of parameter documentation. It only mentions 'persistent ID' for tracks/playlists, which partially explains track_id and playlist_id, but it ignores action semantics, how position_seconds is used, and which parameters are required for which actions. The action enum helps somewhat, but the description itself adds little.
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 clear verb and resource: 'Control playback' and 'play a local track/playlist by persistent ID.' This helps distinguish it from read-oriented siblings like music_get_player_state, but it does not enumerate the full set of actions (pause, seek, next, etc.) or explicitly differentiate from music_set_playback_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description simply states what the tool does without explaining the appropriate context, such as when to use transport controls versus playback options or state queries.
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some detail about the output content (stable IDs, kinds, etc.) but does not disclose behavioral traits like pagination behavior, rate limits, or how filtering works. Since the annotations cover the critical safety aspects, this is adequate but not superior.
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, succinct sentence that front-loads the core action and enumerates useful output attributes. It contains no redundant or filler content, and every phrase contributes meaning. It is appropriately terse for a straightforward list operation.
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?
While annotations and an output schema exist, the description is incomplete because it fails to explain the five optional parameters, which are all undocumented in the schema. There is no mention of filtering, pagination, or default behavior, and no guidance relative to sibling tools. For a tool with multiple parameters and a complex ecosystem of related tools, this description leaves too much to inference.
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?
The schema description coverage is 0%, meaning the description must explain the parameters (kind, limit, cursor, parent_id, root_only) to compensate. It does not mention any of these parameters or their semantics. The phrase 'kinds' in the description is the only tenuous link, but it does not explain how the kind parameter filters results. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List playlists') and identifies the resource, which distinguishes it from singular getters like music_get_playlist. It also specifies key output attributes (stable IDs, kinds, parents, counts, mutation capabilities), giving a clear sense of what the tool returns. However, it does not explicitly differentiate itself from related list tools (e.g., list_playlist_tracks), so it isn't a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as music_get_playlist or music_list_playlist_tracks. The description does not mention filtering options, pagination, or any context for selecting this tool. With no usage context, an agent must infer appropriateness from the name alone.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds 'stable IDs' as useful behavioral context, but does not disclose other behavior such as pagination mechanics, default sorting, or field selection implications, which are relevant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action, and contains no filler. It is concise and readable, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, a nested TrackFilters object, and no mention of pagination, sorting defaults, or when to use this over music_get_tracks, the description is insufficient for an agent to invoke the tool correctly in varied scenarios. The rich schema is not complemented by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the seven parameters. The phrase 'metadata filters' hints at the filters object, but there is no detail about filter fields, sort enums, cursor usage, or limit behavior, leaving the schema as the sole source of parameter meaning.
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 verbs 'search' and 'browse' with the resource 'local library tracks', and mentions 'metadata filters and stable IDs', which clearly indicates the tool's function. It does not explicitly differentiate from sibling music_get_tracks, but the metadata filter phrase provides a distinguishing feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like music_get_tracks. The description simply states what the tool does without mentioning contexts, prerequisites, or exclusions, leaving the agent without clear usage direction.
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?
Annotations already indicate this is a non-read-only operation, and the description merely says 'Set' without adding any behavioral nuances. It does not disclose whether unspecified options are left unchanged, whether changes are immediate, or any permission requirements. The description adds little beyond the 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?
The description is a single, compact sentence that immediately states the action and the covered settings. There is no unnecessary verbosity, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested options object, multiple settings, sibling tools like music_control_playback), the description is too brief. It does not explain the partial-update semantics, the structure of the options object, or how AirPlay device IDs are selected. The presence of an output schema does not offset these gaps because the description alone leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and while the description lists the editable properties, it fails to explain that these are nested inside the required 'options' object. This omission could confuse an agent into thinking it can set them as top-level parameters. The description does not compensate for the lack of schema documentation in prose.
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 ('Set') and lists the exact resources (volume, mute, shuffle, repeat, EQ, AirPlay output), clearly distinguishing it from siblings like music_control_playback. It fully conveys the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of music_control_playback or music_list_playback_targets, nor any exclusions for cases where this tool is not appropriate. The usage context is implied but never explicitly stated.
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 annotation readOnlyHint: false already indicates a write operation, and destructiveHint: false indicates non-destructive. The description adds context that this cancellation does not alter the music itself, which is helpful. However, it does not disclose other side effects, such as whether the plan is permanently discarded or if there are any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that leads with the verb 'Cancel' and immediately clarifies the non-impact on Music. Every word adds value, and there is no superfluous information.
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 one-parameter cancellation operation, the description is sufficient in conjunction with the output schema and annotations. However, it does not address edge cases such as whether the plan must be in a 'pending' state or what happens if the plan is not found. Also, no mention is made of how this tool relates to sibling cancellation/undo operations, leaving the agent to infer usage from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter (plan_id) with no description, and the tool description also says nothing about it. Since schema coverage is 0%, the description must compensate, but it does not add any explanation of what plan_id refers to or how to obtain it. The parameter name is somewhat self-explanatory, but the lack of explicit semantics is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and the resource ('a pending plan'), and adds the qualifier 'without changing Music' to clarify the scope. It is unambiguous, though it does not explicitly distinguish itself from sibling tools like music_plan_undo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use when you need to cancel a pending plan while leaving the music library unchanged. However, no explicit guidance is given about when not to use it or how it compares to alternatives such as music_plan_undo, which might be appropriate for undoing applied changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral traits (10-minute, single-use token; validation rather than application), but annotations are all false and unhelpful. It does not disclose whether the plan is persisted, if validation is a dry run, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It conveys the core purpose and token details efficiently.
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?
Despite a complex schema and a workflow evident from siblings, the description does not explain how to construct operations, the validation process, or how the token relates to apply_changes. The context is insufficient for an agent to use this tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only vaguely references 'library mutations' while the actual parameter is 'operations' with a complex discriminated union. The description adds minimal 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 clearly states a specific verb ('Validate') and resource ('library mutations'), and distinguishes itself from sibling tools like apply_changes, get_change_plan, and cancel_change_plan by focusing on validation and token issuance.
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 explicit guidance on when to use this tool versus alternatives. It implies a validation step before applying changes, but does not mention the workflow with siblings, prerequisites, or exclusions.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context, only indicating that it returns a single playlist. It doesn't mention error cases or edge conditions, but the annotations carry most of the burden and there's no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action, resource, and key parameter. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects) and the presence of an output schema and clear annotations, the description is largely sufficient. It could improve by noting the outcome when the ID doesn't exist, but the core functionality is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines playlist_id with no description, and schema coverage is 0%. The description adds the modifier 'persistent ID,' which implies the ID is a stable identifier, but doesn't explain how it relates to other tools or how to obtain it. This is some added meaning but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('playlist'), and the qualifier 'by persistent ID' specifies the exact retrieval method. This distinguishes it from sibling tools like music_list_playlists, which lists playlists, and music_list_playlist_tracks, which retrieves tracks within a playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It doesn't mention that you need a persistent ID, how to obtain it, or when to prefer this over listing or searching playlists. The usage context is only implied by the description itself.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a valuable behavioral constraint: it does not expose stored before/after metadata. This goes beyond what annotations provide and clarifies the tool's limited view of the audit history.
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 states the core function and a key limitation without any fluff. Every word earns its place, making it concise and well-structured.
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 simple tool with two optional parameters and an output schema, the description gives a basic understanding of listing audit history but omits usage guidance and parameter semantics. It is minimally viable but has clear gaps in guiding an agent on when to use it and how to paginate through results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two parameters (limit and cursor). The description does not mention either parameter or explain pagination semantics, so it fails to compensate for the schema gap. The parameter names are somewhat self-explanatory, but the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('persistent audit history'), and adds a distinguishing constraint ('without exposing stored before/after metadata') that differentiates it from sibling tools like music_get_change_plan. This clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It merely states what it does without indicating context, prerequisites, or exclusions. There is no explicit or implicit comparison to sibling 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?
Annotations already declare destructiveHint true, and the description adds valuable context about token, expiry, and optimistic concurrency checks. But it omits mention of the irreversible_confirmation parameter and what happens if checks fail.
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, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive with 3 parameters and no schema descriptions, yet the description is minimal. It does not cover preconditions, the confirmation parameter, or failure behavior, making it incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description clarifies plan_id and approval_token via the checks, but it does not mention irreversible_confirmation at all, leaving that parameter's purpose unexplained.
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 applies an approved plan, with specific verb 'Apply' and resource 'plan'. It uniquely identifies this action among siblings like cancel_change_plan or plan_undo.
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 usage after plan approval and after validity checks, giving clear context. However, it does not explicitly mention alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, establishing a safe read operation. The description adds valuable context by specifying that approval token hashes are deliberately not exposed, which is beyond the annotation's scope. However, it doesn't describe what happens for canceled or in-flight plans.
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 conveys the core function and a security caveat without redundancy. 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 get-by-id tool with an output schema and strong annotations, this description is nearly complete. It identifies the action and resource and includes a security constraint, though it remains vague about what constitutes a 'plan' and where plan_id originates, which slightly reduces completeness.
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?
With schema description coverage at 0%, the description was expected to clarify the plan_id parameter, but it contains no parameter information. The single parameter plan_id is self-explanatory from its name, but the description adds no format, source, or validation details, failing to compensate for the absent schema annotations.
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 the specific verb 'Read' and names the resource 'a pending or completed plan,' clearly distinguishing it from sibling tools like music_plan_changes (which likely lists plans) and music_apply_changes (which mutates). The addition of 'without exposing approval token hashes' further specifies the tool's role.
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 a read-only retrieval function but offers no explicit when-to-use guidance or alternatives. It doesn't mention that music_list_changes should be used for enumerating plans or that music_apply_changes is for applying them, leaving the agent to infer from sibling names.
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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting 'current order' (implying playlist ordering) and 'opaque pagination' (indicating cursor-based, not page-number-based pagination), which goes beyond the structured 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?
The description is a single, well-structured sentence with no redundant information. It front-loads the core purpose and includes a key detail (opaque pagination) without fluff.
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 a bare schema (no descriptions) and 4 parameters, yet the description only addresses the 'cursor' behavior. The 'fields' parameter is entirely unexplained, and while the output schema exists, the description leaves significant gaps for a list operation with multiple optional parameters.
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?
With 0% schema description coverage, the description was expected to compensate, but it only hints at cursor via 'opaque pagination'. It does not explain the 'limit', 'fields', or even explicitly identify 'playlist_id' as required, leaving most parameter semantics unexplained.
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 resource ('playlist's tracks') with a clear scope ('in current order with opaque pagination'), effectively distinguishing this from sibling tools like music_list_playlists and music_get_tracks.
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 clearly implies a use case (retrieving tracks of a playlist), but it does not explicitly state when to use this tool over alternatives (e.g., music_get_playlist or music_search_tracks), nor does it mention exclusions or conditions.
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 provide readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context: the 500 ID limit and that results are returned in request order. This goes beyond annotations, though it doesn't discuss error handling or behavior for invalid/duplicate IDs, but that's not critical given the annotations and output schema.
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 leads with the verb 'Resolve'. It includes key constraints (500, order) 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?
Given the presence of an output schema and strong annotations, the description is mostly complete. It covers the essential behavior and constraints. However, it doesn't clarify what 'persistent' means or how the 'fields' option affects results, leaving minor gaps. Still, it's well above minimal for a simple get-by-ID 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?
The description adds meaning for the track_ids parameter (up to 500, persistent IDs) which is not in the schema. However, it provides no explanation for the 'fields' parameter, and with 0% schema description coverage, the agent is left guessing what fields controls. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves persistent track IDs up to 500, preserving request order. This is a specific verb+resource+scope that distinguishes it from siblings like music_list_playlist_tracks or music_search_tracks.
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 is implied: you use this when you have specific track IDs to look up. However, there is no explicit mention of when not to use it or alternatives for finding tracks (e.g., search). The description doesn't mention that for playlists, music_list_playlist_tracks should be used instead.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by clarifying this is a summary operation that does not return the full library, but it does not disclose additional behaviors like performance implications or error conditions.
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 clearly states the action and the resource scope. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, simple output counts) and the presence of an output schema, the description is complete. It accurately conveys that this is a lightweight summary, and no additional context appears needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (vacuously). The description does not need to compensate for parameter details; the baseline of 4 for 0-param tools applies here.
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 returns track and playlist counts, which is a specific verb+resource. It also distinguishes itself from siblings by noting it avoids returning the full library, making its scope evident.
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 a use case (wanting counts without the full library) but does not explicitly name alternatives or provide when-to-use versus when-not-to-use guidance. The phrase 'without returning the full library' gives context, but there are no explicit exclusions or alternative tool references.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds a list of returned state fields, which is useful but does not disclose additional behavioral nuances such as response format or side effects. It does not contradict the 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?
The description is a single sentence with a clear leading verb ('Return') and a concise list of returned attributes. Every word earns its place, with no unnecessary filler or repetition.
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 zero-parameter, read-only state retrieval tool with an output schema, the description adequately lists the key return fields. Simplicity of the tool means no additional context is necessary, and sibling tool names clarify the broader playback API 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 tool has zero parameters, so there are no parameter semantics to clarify. The baseline for 0 params is 4, and the description appropriately focuses on what the tool returns rather than nonexistent 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?
The description clearly identifies the tool as returning the player's state, listing specific attributes such as current track, position, volume, shuffle, repeat, and EQ. This distinguishes it from sibling tools like music_control_playback and music_set_playback_options, which imply mutating 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 usage for retrieving the current playback state, but it does not explicitly state when to use it versus alternatives. There are no exclusions or alternative tool mentions, so guidance is merely implied rather than stated.
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 read-only, idempotent, and non-destructive behavior. The description adds that analysis is deterministic and does not send every track to the AI, which provides useful behavioral expectations beyond the 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?
The description is a single, well-structured sentence that front-loads the core action and resource, omitting unnecessary detail. 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?
Given the presence of a detailed schema, output schema, and annotations, the description covers the essential purpose and behavioral nuance. It could mention the specific analysis kinds, but the enum and output schema fill in the remaining context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must compensate. It mentions library or playlist scope, which clarifies the optional playlist_id parameter. However, it does not explain the kind enum or limit parameter, leaving the self-explanatory enum values to carry much of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: running deterministic analysis on a library or playlist. It explicitly distinguishes itself from AI-based alternatives by noting it does not send tracks to the AI, which differentiates it from sibling tools like music_search_tracks or music_get_library_summary.
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 when to use this tool: when you need local, deterministic analysis without incurring AI costs. It does not explicitly name alternatives or exclusions, but the deterministic/AI-free framing provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no hints (all false), but the description adds behavioral context by explaining that this tool creates a plan rather than directly applying changes. 'Preview-and-approval' indicates a workflow step, disclosing that it likely doesn't mutate the state immediately. No contradiction 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?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the tool's essence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is adequate. It clarifies the tool's role but could be more explicit about what 'reversible part' means or what inputs are expected. Overall sufficient given the tool's simplicity.
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% and the only parameter change_id is not described. The description indirectly implies change_id refers to the prior change, but does not explain its format or meaning explicitly. This partially compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a preview-and-approval plan for the reversible part of a prior change. The verb 'Create' and specific resource 'plan for the reversible part of a prior change' distinguish it from sibling tools like music_plan_changes, which likely plan new changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for undoing or reverting prior changes, specifically their reversible parts. It does not explicitly name alternatives but the wording implies when to use this tool versus planning new changes.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the behavioral detail that the list includes active selections, informing the user that the output highlights currently selected targets. No contradiction 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?
The description is a single sentence, front-loaded with the verb 'List', and contains no extraneous words. It efficiently communicates the entire scope in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter read-only listing tool with an output schema, the description covers the essential purpose. Annotations cover safety, and the output schema covers return value details. Nothing critical is missing for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema places no burden on the description. According to the rubric, zero parameters yields a baseline of 4, and the description does not need to add parameter details.
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 the specific verb 'List' and clearly identifies the resource as 'AirPlay outputs and EQ presets', with the additional detail 'including active selections' which adds specificity. This distinguishes it from sibling tools like music_list_changes or music_get_player_state, which serve different listing purposes.
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?
No explicit guidance is given about when to use this tool versus alternatives like music_set_playback_options or music_control_playback. Usage is implied by the tool's purpose and name, but the description does not state exclusions or context such as when to discover available targets before selecting one.
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, idempotentHint=true, and destructiveHint=false. The description adds specific behavioral context by enumerating what the health check inspects (platform, Music availability, JXA connectivity, writable object kinds), going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and lists all checked items. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description adequately covers the tool's purpose and behavior. It also benefits from strong annotations that clarify safety and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline per rubric is 4. The description doesn't need to explain parameters; the schema is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the verb 'Check' and explicitly lists four distinct health aspects: platform, Music availability, JXA connectivity, and writable object kinds. This is specific and clearly distinguishes it from sibling tools (none of which are health checks).
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 the tool is for environment health verification, and no sibling tool serves this same purpose. However, it doesn't explicitly state when to use it versus alternatives, though the uniqueness among siblings provides sufficient context.
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:

[![apple-music-mcp MCP server](https://glama.ai/mcp/servers/Zheng-Kun/apple-music-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Zheng-Kun/apple-music-mcp)

Score Badge

Copy to your README.md:

[![apple-music-mcp MCP server](https://glama.ai/mcp/servers/Zheng-Kun/apple-music-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Zheng-Kun/apple-music-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/Zheng-Kun/apple-music-mcp'

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