MCP server for music attribution and permission queries. Implements the Permission Patchbay enabling AI platforms to query training rights, attribution provenance, and permission scopes before incorporating musical works. Provides tools for querying attribution records, checking permissions, and listing permission bundles.
The Music Attribution MCP server has 7 tools with functional schemas and descriptions, but falls well short of production-grade quality. All tools have descriptions and input parameters with types, which prevents automatic failure; however, the descriptions are generic and lack the specificity required for LLM-driven agent planning. None of the tools include output schema documentation, which is critical for agents to understand what fields to expect and how to chain calls. The server exhibits no error handling guidance, no tool annotations (readOnlyHint/destructiveHint), and no discussion of pagination or result limits for search operations. The tool naming follows verb_noun convention (query_, check_, list_, explain_, search_, suggest_, submit_), which is acceptable but generic. Parameter descriptions are present but brief (averaging ~40-60 chars) and lack constraint details (e.g., UUID format is mentioned but not validated in the schema itself). Two tools marked WRITE (suggest_correction, submit_feedback) lack any confirmation mechanism or guidance on handling partial failures. The overall structure suggests a research prototype rather than a production tool designed for agentic composition.
Check a specific permission for an entity
Explain the confidence score for an attribution record
List all permissions for an entity
Query attribution by work entity ID
Search attribution records by title, artist, or keyword
Submit structured feedback for an attribution record
Suggest a correction to an attribution record field
No output schemas documented for any tool. Agents cannot plan downstream calls or extract required fields without blind trial-and-error. This is a critical gap for agentic composition.
search_attributions accepts 'query' string but provides no pagination parameters (limit, offset, page_size) or guidance on result limits. Large result sets will blow context windows and degrade LLM reasoning.
suggest_correction and submit_feedback are marked WRITE (destructive) but lack any confirmation mechanism, dry-run capability, or error recovery guidance. Agents may corrupt attribution records without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Agents cannot distinguish safe-to-retry tools from irreversible operations without explicit metadata.
Permission type parameter in check_permission mentions 'must match a PermissionTypeEnum value, e.g. AI_TRAINING, COMMERCIAL_USE' but does not declare an enum constraint in the schema. LLMs will hallucinate invalid permission types.
Tool descriptions are too brief (35 - 50 chars on average) and lack context for agent selection. E.g., 'Query attribution by work entity ID' does not explain when to use this vs search_attributions, or what 'attribution' means in domain terms.
No error handling guidance present. Tools return errors (implied) but provide no recovery hints. E.g., if work_id is not found, should the agent search first? Fallback to a different endpoint?