musicbrainz-mcp-server
Server Details
Search MusicBrainz artists, releases, works, labels; resolve ISRC/ISWC/barcode; fetch cover art.
- Status
- Healthy
- Uptime
- 100.0% over 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/musicbrainz-mcp-server
- GitHub Stars
- 1
- Server Listing
- musicbrainz-mcp-server
TDQS
Scored across 10 tools
Each get_* tool targets a distinct MusicBrainz entity type, while browse_entities, lookup_identifier, and search_entities each occupy clearly separate access patterns: enumeration, identifier resolution, and full-text search. The descriptions explicitly cross-reference when one tool should be used instead of another (e.g., browse_entities for complete linked sets vs. get_* for single entities), so there is no practical ambiguity.
All tools share the musicbrainz_ prefix and follow a consistent verb_noun pattern: get_artist, get_label, get_release, browse_entities, lookup_identifier, search_entities. The verbs get/browse/lookup/search clearly signal different operations, and entity names are uniform across getters.
Ten tools is well-scoped for a read-only MusicBrainz MCP server: seven entity/detail getters cover the core entity types, plus browse, search, and identifier lookup cover the remaining primary API access patterns. No tool feels redundant, and the count is appropriate for the domain's complexity.
The surface covers all major MusicBrainz entity types (artist, label, release, release-group, recording, work), cover art, full-text search, identifier lookup (ISRC/ISWC/barcode), and complete enumeration via browse_entities. For a read-only metadata server, there are no obvious dead ends: search/lookup resolve to MBIDs, getters provide detail, and browse handles paginated linked sets.
Available Tools
10 toolsmusicbrainz_browse_entitiesmusicbrainz-mcp-server: browse entitiesARead-onlyIdempotentInspect
Paginate the COMPLETE set of entities linked to a parent MBID — every release-group by an artist, every release on a label, every recording of a work, every release in a release-group. This is the only complete-enumeration path: the get_* tools embed at most one page (25) of any linked list, so use this tool whenever a linked set may exceed a page (a prolific artist, a major label with thousands of releases, a heavily-covered work). Provide exactly ONE link MBID matching a valid parent→child relationship for the target_type. Pages arbitrarily deep via offset; totalCount is the true upstream total.
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | Exactly one parent MBID. The valid key depends on target_type (see the description). | |
| limit | No | Page size (1–100). | |
| offset | No | Result offset for deep pagination (0-based). | |
| target_type | Yes | The entity type to enumerate (the children). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The page size that was applied. Absent when not truncated. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of entities returned in this page. Absent when not truncated. |
| notice | No | How to page further when results remain, or guidance when empty. |
| offset | No | The offset used for this page. |
| entities | No | This page of linked entities, in upstream order. |
| linkMbid | No | The parent MBID that was browsed. |
| linkType | No | The parent link type used (artist, label, release-group, recording, work, or area). |
| truncated | No | True when more entities remain beyond this page (offset + shown < totalCount). Absent when the page is complete. |
| targetType | No | The entity type that was enumerated. |
| totalCount | No | True total number of linked entities upstream (the {type}-count field). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal read-only, open-world, and idempotent behavior; the description adds valuable operational details like deep pagination via offset, totalCount as the true upstream total, and the exact-one-link requirement. Nothing contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then moves directly to when to use it, constraints, and pagination behavior. Every sentence contributes meaningful guidance with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool with nested link objects, enums, and pagination; the description provides enough context to use it effectively and safely. The output schema and detailed annotations fill in the remaining structured details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the main description strengthens understanding by requiring exactly one link MBID and clarifying parent-child relationships. Offset and limit semantics are also explained beyond their schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action—paginate the COMPLETE set of entities linked to a parent MBID—and gives concrete examples across target types. It also differentiates itself from the get_* siblings by explicitly being the only complete-enumeration path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit when-to-use rule: whenever a linked set may exceed the single 25-item page returned by get_* tools. It also states the main constraint—exactly one link MBID and a valid parent-child relationship—which helps prevent incorrect invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_artistmusicbrainz-mcp-server: get artistARead-onlyIdempotentInspect
Artist profile by MBID: type (person/group/…), country, life span, gender, area, aliases, tags/genres, plus the discography (release-groups) and band-membership / collaboration relationships and external links (Wikidata QID, Discogs, official site — surfaced as url-rels chainable to those servers). The 80% artist-detail call. Discography and relationships are capped at one page (25); for a prolific artist's complete release-group list, call musicbrainz_browse_entities with target_type=release-group and the artist link.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Artist MBID (36-character UUID). | |
| inc_relationships | No | Include band-membership / collaboration relationships and external links (url-rels). | |
| inc_release_groups | No | Include the discography (release-groups). Capped at one page; use browse for the full set. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The one-page cap that was applied. Absent when not truncated. |
| area | No | Associated area name. Omitted when unknown. |
| mbid | No | Artist MBID. |
| name | No | Artist name. |
| tags | No | Community tags/genres with vote counts (may be empty). |
| type | No | Artist type (Person, Group, Orchestra, …). Omitted when unknown. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of release-groups returned. Absent when not truncated. |
| gender | No | Gender, for person-type artists. Omitted when unknown/inapplicable. |
| notice | No | How to fetch the complete discography when truncated. |
| aliases | No | Alternate names (may be empty). |
| country | No | ISO country code. Omitted when unknown. |
| lifeSpan | No | Birth/death or formation/dissolution span. Omitted when unknown. |
| sortName | No | Sortable name form. Omitted when absent. |
| truncated | No | True when the discography hit the one-page cap and more release-groups exist. Absent when the full set fit in one page. |
| externalLinks | No | External resource links (url-rels) — Wikidata, Discogs, official site (may be empty). |
| relationships | No | Band membership and collaboration relationships (may be empty). |
| releaseGroups | No | Discography — release-groups (one page; may be empty or capped). |
| disambiguation | No | Short qualifier distinguishing same-named artists. Omitted when absent. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld hints, so the description does not need to restate safety. It adds useful behavioral context: the one-page cap, the content included in the profile, and that external links are url-rels chainable to external servers. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key content details and the important limitation/alternative. Three sentences cover what the tool returns, its scope, and when to switch tools; no sentence is wasted or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only artist lookup with a rich output schema and strong annotations, the description is complete. It covers the primary use case, the data returned, the pagination cap, and an alternative for extended results, so an agent can confidently select and invoke the tool without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents mbid and the two boolean flags thoroughly. The description repeats the cap and browse alternative already present in the inc_release_groups parameter description, but does not add new parameter-level meaning beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Artist profile by MBID' and enumerates concrete content: type, country, life span, gender, area, aliases, tags/genres, discography, relationships, and external links. It also distinguishes itself from siblings by identifying itself as 'The 80% artist-detail call' and pointing to browse_entities for the complete list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is explicit: this is the go-to artist-detail call, with a clear caveat that discography and relationships are capped at one page (25). For a full release-group list, the description explicitly directs the agent to musicbrainz_browse_entities with target_type=release-group and the artist link, providing a concrete alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_cover_artmusicbrainz-mcp-server: get cover artARead-onlyIdempotentInspect
Cover Art Archive images for a release or release-group MBID: front/back flags, image types, full-resolution URLs, and 250/500/1200px thumbnail URLs. Returns an empty image set (NOT an error) when the entity has no art — absence of art is information. An MBID that matches no release or release-group of the given entity_type fails with entity_not_found instead of an empty set. Art is served at the release level; a release-group MBID resolves to a representative release's art automatically. URLs are linked, never rehosted — image copyright stays with the rights holders (only MusicBrainz core metadata is CC0).
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Release or release-group MBID (36-character UUID). | |
| entity_type | No | Whether the MBID is a release (default) or a release-group. | release |
Output Schema
| Name | Required | Description |
|---|---|---|
| mbid | No | The MBID that was queried. |
| error | No | Present when the call failed. Absent on success. |
| hasArt | No | Whether any cover art exists for this entity. |
| images | No | Cover-art images (empty when the entity has no art). |
| notice | No | Present when the entity has no art: states that no images exist, or — when the MBID could not be checked against MusicBrainz — that its existence is unconfirmed. |
| entityType | No | Whether the MBID was treated as a release or release-group. |
| representativeRelease | No | For a release-group query, the release MBID whose art was returned. Omitted for direct release queries. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description goes well beyond these by disclosing critical edge-case behavior: empty image set on absence of art (not an error), entity_not_found on mismatched MBID, automatic resolution from release-group to a representative release, and the linking (never rehosting) policy with copyright implications. This is rich, non-obvious behavior that an agent must know to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each dense with information and no fluff. The core purpose and outputs are front-loaded, followed by edge-case behavior (empty set, invalid MBID, release-group resolution) and finally the linking/copyright note. Every sentence earns its place; the structure is logical and scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and a provided output schema, the description is exceptionally complete. It covers expected outputs, edge cases (no art, invalid MBID), resolution semantics, and a licensing caveat. Nothing an agent needs to correctly call this tool and interpret its results is missing. The output schema handles return structure, so the description need not repeat it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'mbid' and 'entity_type' have descriptions including the default and enum. The description adds meaningful above-schema context—how entity_type influences resolution (release-group resolves to a representative release's art) and the consequence of a mismatched MBID (entity_not_found). It also clarifies that art is served at release level, which directly informs parameter choice. This goes beyond mere restatement of schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get'), a precise resource ('Cover Art Archive images'), and the target entities ('release or release-group MBID'). It enumerates concrete outputs (front/back flags, image types, full-resolution URLs, thumbnail URLs), making it unmistakably distinct from sibling tools that fetch artist, label, recording, release, or work metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly infers when to use this tool (whenever cover art is needed for a release or release-group) and includes a behavioral nuance about release-group resolution. However, it does not explicitly state when NOT to use it or name alternatives; the clear separation from sibling tools is implicit rather than spelled out, which is adequate but not maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_labelmusicbrainz-mcp-server: get labelARead-onlyIdempotentInspect
Label by MBID: type (Original Production, Reissue, Imprint, …), country, life span, label code (the LC number), area, aliases, tags, and external links (url-rels — Wikidata, Discogs, official site). A label's releases are a potentially huge linked set (a major label can have tens of thousands), so they are NOT embedded here — enumerate them with musicbrainz_browse_entities (target_type=release, link.label).
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Label MBID (36-character UUID). |
Output Schema
| Name | Required | Description |
|---|---|---|
| area | No | Associated area name. Omitted when unknown. |
| mbid | No | Label MBID. |
| name | No | Label name. |
| tags | No | Community tags/genres (may be empty). |
| type | No | Label type. Omitted when unknown. |
| error | No | Present when the call failed. Absent on success. |
| aliases | No | Alternate names (may be empty). |
| country | No | ISO country code. Omitted when unknown. |
| lifeSpan | No | Founding/dissolution span. Omitted when unknown. |
| sortName | No | Sortable name form. Omitted when absent. |
| labelCode | No | Label code (LC number), without the "LC" prefix. Omitted when absent. |
| externalLinks | No | External resource links (url-rels) (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add extra context. It adds that releases are excluded due to size and that they can be browsed separately, which is important behavioral disclosure not captured by annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists the returned fields, the second explains the release exclusion and points to an alternative. It is front-loaded, informative, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description fully covers what the tool returns, what it excludes, and how to get the excluded data. Combined with annotations, it provides complete guidance for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'mbid' as 'Label MBID (36-character UUID)'. The description only repeats 'by MBID' without adding new parameter semantics, yielding the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Label by MBID' and lists the specific data fields (type, country, life span, label code, area, aliases, tags, external links). It distinguishes from sibling tools by focusing on the label entity and explicitly notes that releases are not included, differentiating from browse_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'they are NOT embedded here — enumerate them with musicbrainz_browse_entities (target_type=release, link.label)', providing a clear when-not-to-use and naming the alternative tool. It also implies when to use this tool (when label details are needed) implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_recordingmusicbrainz-mcp-server: get recordingARead-onlyIdempotentInspect
Recording (a specific performance/track, distinct from the abstract work) by MBID: length, artist credits, ISRCs, the releases it appears on, the work(s) it performs (work-rels — chain to musicbrainz_get_work), and performance/production relationships (who played, produced, engineered, conducted — each with the role and the credited artist MBID). Relationships are capped at one page; for a heavily-covered recording call musicbrainz_browse_entities with target_type=recording and link.work.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Recording MBID (36-character UUID). | |
| inc_relationships | No | Include performance/production relationships (performers, producers, engineers) and work-rels. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mbid | No | Recording MBID. |
| error | No | Present when the call failed. Absent on success. |
| isrcs | No | ISRCs assigned to this recording (may be empty). |
| title | No | Recording title. |
| length | No | Recording length as m:ss. Omitted when unknown. |
| releases | No | Releases this recording appears on (may be empty). |
| artistCredit | No | Credited artists (may be empty). |
| externalLinks | No | External resource links (url-rels) (may be empty). |
| relationships | No | Performance/production relationships and work-rels (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
| firstReleaseDate | No | Earliest release date for this recording. Omitted when absent. |
| artistCreditString | No | Display string of the artist credit with join phrases. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds behavioral context beyond these by stating that relationships are capped at one page, which is a significant limitation, and mentions the pagination alternative. It also clarifies the scope of included relationships and the role of MBIDs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the purpose and then lists content. It manages to include all key behavioral and contextual details without redundancy. While it is longer than average, every phrase contributes information, and the structure (purpose, contents, limitation/alternative) is logical. Not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (has output schema: true), the description need not explain return format. It covers the tool's inputs, what data is returned, the pagination cap, and the recommended alternative for heavy cases. Combined with the rich annotations, the description is fully complete for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters (mbid and inc_relationships) with clear descriptions. The tool description adds minimal parameter-specific insight beyond reinforcing 'by MBID' and linking work-rels, but it does not need to because the schema already documents the parameters adequately. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a recording (a specific performance/track) by MBID, distinguishing it from the abstract work. It enumerates the specific data returned (length, credits, ISRCs, releases, works, relationships), making the tool's function unambiguous and differentiating it from sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by identifying the tool as for recordings by MBID and includes an explicit alternative: 'for a heavily-covered recording call musicbrainz_browse_entities with target_type=recording and link.work.' It also implies a chaining pattern via 'work-rels — chain to musicbrainz_get_work', indicating when to use that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_releasemusicbrainz-mcp-server: get releaseARead-onlyIdempotentInspect
One edition's full detail by MBID: the tracklist (media → tracks → recordings with lengths and recording MBIDs), label + catalog number, barcode, country, release date, format, packaging, text representation (language/script), and a cover-art availability stub. Track lengths are rendered m:ss (stored as milliseconds upstream). For the actual cover image URLs, call musicbrainz_get_cover_art with this release MBID.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Release MBID (36-character UUID). |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | Release date. Omitted when absent. |
| mbid | No | Release MBID. |
| error | No | Present when the call failed. Absent on success. |
| media | No | Media (discs) with their tracklists (may be empty). |
| title | No | Release title. |
| script | No | Text-representation script code. Omitted when absent. |
| status | No | Release status (Official, Promotion, Bootleg, …). Omitted when absent. |
| barcode | No | Barcode (UPC/EAN). Omitted when absent; empty string upstream means "known to have none". |
| country | No | Release country code. Omitted when absent. |
| coverArt | No | Whether cover art exists (availability stub from WS/2). |
| language | No | Text-representation language code. Omitted when absent. |
| labelInfo | No | Label / catalog-number pairings (may be empty). |
| packaging | No | Packaging type (Jewel Case, Digipak, …). Omitted when absent. |
| artistCredit | No | Credited artists (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
| releaseGroupId | No | Parent release-group MBID — chain to musicbrainz_get_release_group. Omitted when absent. |
| artistCreditString | No | Display string of the artist credit with join phrases. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already include readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating a safe read operation. The description adds value beyond that by disclosing that track lengths are converted from milliseconds to m:ss format, a behavioral detail not in annotations, and noting a 'cover-art availability stub' (not actual images), which sets expectations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it opens with a clear purpose, lists key data items in a parenthetical, and ends with a specific redirect to a sibling tool. Every sentence serves a purpose (purpose, data details, format note, alternative usage), with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) with strong annotations and an output schema present. The description covers all essential aspects: what data is returned, units conversion, and how to get cover art. It is complete for the tool's complexity, and the output schema handles return value details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the single parameter with a clear description ('Release MBID (36-character UUID).'). The description adds context by referencing 'this release MBID' in the cover art instruction, reinforcing the parameter's role. Since schema coverage is high and description adds minimal but useful context, a 4 is appropriate; it exceeds the baseline 3 by clarifying the parameter's usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'One edition's full detail by MBID' and enumerates the specific data returned (tracklist, label, catalog number, barcode, etc.). It distinguishes itself from siblings by explicitly pointing to musicbrainz_get_cover_art for actual cover images, and is distinct from other get_* tools by focusing on release-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes usage guidance: 'For the actual cover image URLs, call musicbrainz_get_cover_art with this release MBID.' This tells the agent when to use a different tool, which is clear and helpful. It also implies use when a specific release's full details are needed, and the covered fields set a clear scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_release_groupmusicbrainz-mcp-server: get release groupARead-onlyIdempotentInspect
Release-group ("the album" above specific pressings) by MBID: primary type (Album/Single/EP) and secondary types (Live/Compilation), first-release date, artist credit, the list of releases (editions), tags/genres, and cover-art availability from the Cover Art Archive (image count and front/back flags for the release-group's representative release — the art musicbrainz_get_cover_art returns; use that tool for the image URLs). The embedded releases list is capped at one page (25); for the complete set of editions, call musicbrainz_browse_entities with target_type=release and link.release-group. For a specific edition's tracklist, take a release MBID from the releases list and call musicbrainz_get_release.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Release-group MBID (36-character UUID). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The one-page cap that was applied. Absent when not truncated. |
| mbid | No | Release-group MBID. |
| tags | No | Community tags/genres (may be empty). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of releases returned. Absent when not truncated. |
| title | No | Release-group title. |
| notice | No | Present when the releases list was capped (how to fetch the complete set of editions) and/or when cover-art availability could not be checked (why coverArt is omitted). |
| coverArt | No | Cover-art availability from the Cover Art Archive: the images of the release-group's representative release, the same art musicbrainz_get_cover_art returns (exists: false with count 0 when the archive has none). Omitted when the archive lookup could not complete — the notice says so. |
| releases | No | Releases (editions) in this group (one page; may be empty or capped — use browse for all). |
| truncated | No | True when the releases list hit the one-page cap and more editions exist. Absent when the full set fit in one page. |
| primaryType | No | Primary type (Album, Single, EP, Broadcast, Other). Omitted when absent. |
| artistCredit | No | Credited artists (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
| secondaryTypes | No | Secondary types (Live, Compilation, Soundtrack, …). Omitted when none. |
| firstReleaseDate | No | Earliest release date across all editions. Omitted when absent. |
| artistCreditString | No | Display string of the artist credit with join phrases. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses the pagination cap (25), the representative-release scoping of cover art flags, and the data fields returned. It also clarifies what the tool does not return (image URLs and full edition sets), which is crucial for correct usage. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it front-loads the core return fields, then adds the page cap, then routes to alternatives. Every sentence earns its place; it is neither verbose nor under-specified for the informational load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's rich output (release group with multiple data facets), the description covers the essential return items, the limitation on releases list, and provides explicit pointers for what is not included. Even though an output schema exists, the description ensures an agent knows exactly what to expect and what to follow up with.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, mbid, is fully documented in the schema (100% coverage) as a release-group MBID. The description merely restates 'by MBID' without adding format or interaction details beyond the schema, so the baseline of 3 applies—it adds nothing beyond the schema but the schema already covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a release group by MBID, lists the exact content (primary/secondary types, first-release date, artist credit, releases, tags/genres, cover-art info), and explicitly differentiates from sibling tools by referencing get_cover_art, get_release, and browse_entities. This is a specific verb+resource with clear boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives precise when-to-use alternatives: for complete editions call musicbrainz_browse_entities with target_type=release; for a specific edition's tracklist call musicbrainz_get_release; for image URLs call musicbrainz_get_cover_art. It also notes the releases list is capped at one page, so usage is fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_get_workmusicbrainz-mcp-server: get workARead-onlyIdempotentInspect
Work (a composition — the song as written, distinct from any specific recording) by MBID: type, language(s), ISWCs (the work-level standard identifier), writer/composer/lyricist relationships (with the credited artist MBID), aliases, tags, and the recordings that perform it. The recording relationships are returned in full (the work lookup does not page them).
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | Work MBID (36-character UUID). | |
| inc_relationships | No | Include writer/composer relationships, recording relationships, and external links. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mbid | No | Work MBID. |
| tags | No | Community tags/genres (may be empty). |
| type | No | Work type (Song, Symphony, …). Omitted when unknown. |
| error | No | Present when the call failed. Absent on success. |
| iswcs | No | ISWCs assigned to this work (may be empty). |
| title | No | Work title. |
| aliases | No | Alternate titles (may be empty). |
| languages | No | Lyrics languages (ISO codes; may be empty). |
| externalLinks | No | External resource links (url-rels) (may be empty). |
| relationships | No | Writer/composer/lyricist relationships and recording-rels — the complete set (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds a valuable behavioral detail: 'The recording relationships are returned in full (the work lookup does not page them),' which goes beyond the annotations. This helps the agent understand the return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the definition and then lists content. Every phrase adds value, with no filler. The list is long but compact, making it efficient if slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, annotations, and a detailed description, the tool is well-covered. The description covers the main return fields and the non-paging behavior. It could mention error handling or rate limits, but those are not specified and are likely covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description repeats the list of included relationships but does not add new parameter-specific semantics. It clarifies the concept of a work but not the syntax or behavior of the parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a work by MBID, defining 'work' as a composition distinct from recordings. It lists specific fields returned (type, languages, ISWCs, relationships, aliases, tags, recordings), which distinguishes it from sibling get_* tools for other entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: fetch a work by its MBID. It does not explicitly mention alternatives or exclusions, but the tool name and definition imply the appropriate use case. A more explicit 'use this instead of X when...' would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_lookup_identifiermusicbrainz-mcp-server: lookup identifierARead-onlyIdempotentInspect
Resolve a standard identifier to MusicBrainz entities without a name search — the deterministic path when you already hold an ID. id_type=isrc → recordings (a recording-level code, often shared by several recordings); id_type=iswc → works (a composition-level code); id_type=barcode → releases (UPC/EAN digits; spaces and hyphens are ignored). ISRC and ISWC hit dedicated exact endpoints; barcode is a Lucene search filter so results are ranked (exact match scores 100). The output kind field tells you which entity type came back.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The identifier value. ISRC e.g. "USRC17607839"; ISWC e.g. "T-010.140.236-1"; barcode = the UPC/EAN digits, e.g. "075678164125" (spaces and hyphens are ignored; any other character, including a wildcard, is rejected). | |
| id_type | Yes | Which standard identifier: isrc (recording), iswc (work), or barcode (release). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| result | No | The resolved entities, discriminated by `kind` (recordings | works | releases). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds key behavioral context: ISRC/ISWC hit dedicated exact endpoints, while barcode is a Lucene search filter with ranked results and exact matches scoring 100. It also tells agents to expect a kind field identifying the returned entity type. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, all load-bearing, with the core decision first and mode-specific nuances following. It avoids repeating the schema and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with a full input schema and an output schema, the description covers the workflow decision, endpoint behavior differences, and output shape signal. Nothing an agent needs to correctly invoke or interpret the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters completely, and the description enriches them by explaining what each identifier type represents, that ISRC can map to multiple recordings, and that barcode results are ranked with exact matches at 100. This is genuine added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-resource pair ('Resolve a standard identifier to MusicBrainz entities') and immediately contrasts it with name search, establishing this as the deterministic ID-based lookup. It maps each id_type to its entity class, which clearly distinguishes it from the musicbrainz_search_entities and musicbrainz_get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as the deterministic path when an ID is already held, and says 'without a name search', which sets a clear boundary against search_entities. The id_type mapping also tells agents which entity type each mode returns. It does not name sibling tools directly, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musicbrainz_search_entitiesmusicbrainz-mcp-server: search entitiesARead-onlyIdempotentInspect
Full-text search across a MusicBrainz entity type (artist, release-group, release, recording, work, label) using a Lucene query string. Returns ranked matches with MBID, name/title, disambiguation, type, and a 0–100 relevance score (100 = exact). Starting point when resolving a name to an MBID — chain the returned MBID into the matching musicbrainz_get_* tool. Results are in MusicBrainz score-descending order. Supports field-scoped Lucene syntax (e.g. artist:radiohead AND country:GB).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1–100). | |
| query | Yes | Lucene query string; must contain non-whitespace text. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported. Sent to MusicBrainz exactly as given. | |
| offset | No | Result offset for pagination (0-based). | |
| entityType | Yes | Which entity type to search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when zero results matched — how to broaden or correct the query. |
| results | No | Ranked matches, in MusicBrainz score-descending order. |
| entityType | No | The entity type that was searched. |
| totalCount | No | Total matches upstream before the limit/offset window. |
| effectiveQuery | No | The query string as sent to MusicBrainz. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds valuable behavior beyond the annotations: ranked results, 0–100 relevance scoring with 100 meaning exact, score-descending ordering, and support for field-scoped Lucene syntax. This materially helps an agent predict results before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. It front-loads the core purpose, then adds return behavior, ordering, relevance scoring, and query syntax — every sentence contributes meaningful guidance without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is present and annotations cover read-only/idempotent behavior, the description supplies the remaining context an agent needs: entity type scope, Lucene syntax capabilities, score meaning, result ordering, and a clear follow-up action via the matching get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters well. The description reinforces the query semantics with a Lucene example and notes that the query string is sent to MusicBrainz exactly as given, but it adds only modest meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Full-text search'), a clear resource ('a MusicBrainz entity type'), and enumerates the exact entity types. It also distinguishes this from sibling get/browse tools by framing it as the 'Starting point when resolving a name to an MBID' and describing Lucene-based full-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: resolving a name to an MBID, then chaining into the matching musicbrainz_get_* tool. It does not explicitly exclude browse_entities or state when not to use this tool, but the intended workflow and follow-up action are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- Changed
musicbrainz_get_cover_art3 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (the upstream returns HTTP 400). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel — a value MusicBrainz rejects outright (HTTP 400). `entity_not_found`: The MBID is well-formed but no entity of the given entity_type exists with it (the archive returns 404 and the MusicBrainz check of the MBID returns 404). Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_mbid" -]New value: +[ + "invalid_mbid", + "entity_not_found" +] - changed
Output schema / properties / notice / descriptionPrevious value: -"Notice when no art exists for the entity."New value: +"Present when the entity has no art: states that no images exist, or — when the MBID could not be checked against MusicBrainz — that its existence is unconfirmed."
- Changed
musicbrainz_get_release_group3 fields changed- changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "mbid", - "title", - "artistCredit", - "artistCreditString", - "releases", - "tags", - "coverArt" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "title", + "artistCredit", + "artistCreditString", + "releases", + "tags" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / coverArt / descriptionPrevious value: -"Whether cover art exists (availability stub from WS/2)."New value: +"Cover-art availability from the Cover Art Archive: the images of the release-group's representative release, the same art musicbrainz_get_cover_art returns (exists: false with count 0 when the archive has none). Omitted when the archive lookup could not complete — the notice says so." - changed
Output schema / properties / notice / descriptionPrevious value: -"How to fetch the complete list of editions when truncated."New value: +"Present when the releases list was capped (how to fetch the complete set of editions) and/or when cover-art availability could not be checked (why coverArt is omitted)."
- Changed
musicbrainz_lookup_identifier3 fields changed- changed
Input schema / properties / value / descriptionPrevious value: -"The identifier value. ISRC e.g. \"USRC17607839\"; ISWC e.g. \"T-010.140.236-1\"; barcode e.g. \"075678164125\"."New value: +"The identifier value. ISRC e.g. \"USRC17607839\"; ISWC e.g. \"T-010.140.236-1\"; barcode = the UPC/EAN digits, e.g. \"075678164125\" (spaces and hyphens are ignored; any other character, including a wildcard, is rejected)." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `identifier_not_found`: The identifier is well-formed but resolves to zero entities. `invalid_identifier`: The ISRC/ISWC is malformed (the dedicated endpoint returns HTTP 400). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `identifier_not_found`: The identifier is well-formed but resolves to zero entities. `invalid_identifier`: The ISRC/ISWC is malformed (the dedicated endpoint returns HTTP 400), or the barcode contains anything other than digits once spaces and hyphens are removed. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / result / oneOfPrevious value: -[ - { - "additionalProperties": false, - "description": "ISRC result arm: recordings carrying the ISRC.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "recordings", - "description": "ISRC resolved to recordings.", - "type": "string" - }, - "recordings": { - "description": "Recordings carrying this ISRC.", - "items": { - "additionalProperties": false, - "description": "A recording carrying the looked-up ISRC.", - "properties": { - "artistCredit": { - "description": "Credited artist string; falls back to \"Unknown artist\" when none is recorded.", - "type": "string" - }, - "length": { - "description": "Recording length as m:ss. Omitted when unknown.", - "type": "string" - }, - "mbid": { - "description": "Recording MBID — chain to musicbrainz_get_recording.", - "type": "string" - }, - "title": { - "description": "Recording title.", - "type": "string" - } - }, - "required": [ - "mbid", - "title", - "artistCredit" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "recordings" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "ISWC result arm: works carrying the ISWC.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "works", - "description": "ISWC resolved to works.", - "type": "string" - }, - "works": { - "description": "Works carrying this ISWC.", - "items": { - "additionalProperties": false, - "description": "A work carrying the looked-up ISWC.", - "properties": { - "mbid": { - "description": "Work MBID — chain to musicbrainz_get_work.", - "type": "string" - }, - "title": { - "description": "Work title.", - "type": "string" - }, - "type": { - "description": "Work type. Omitted when absent.", - "type": "string" - } - }, - "required": [ - "mbid", - "title" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "works" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Barcode result arm: releases carrying the barcode.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "releases", - "description": "Barcode resolved to releases.", - "type": "string" - }, - "releases": { - "description": "Releases carrying this barcode (ranked).", - "items": { - "additionalProperties": false, - "description": "A release carrying the looked-up barcode.", - "properties": { - "artistCredit": { - "description": "Credited artist string.", - "type": "string" - }, - "country": { - "description": "Release country code. Omitted when absent.", - "type": "string" - }, - "date": { - "description": "Release date. Omitted when absent.", - "type": "string" - }, - "mbid": { - "description": "Release MBID — chain to musicbrainz_get_release.", - "type": "string" - }, - "score": { - "description": "Lucene relevance score, 0–100 (barcode is a search filter; exact = 100).", - "type": "number" - }, - "title": { - "description": "Release title.", - "type": "string" - } - }, - "required": [ - "mbid", - "title", - "artistCredit", - "score" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "releases" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "description": "ISRC result arm: recordings carrying the ISRC.", + "properties": { + "identifier": { + "description": "The looked-up identifier value.", + "type": "string" + }, + "kind": { + "const": "recordings", + "description": "ISRC resolved to recordings.", + "type": "string" + }, + "recordings": { + "description": "Recordings carrying this ISRC.", + "items": { + "additionalProperties": false, + "description": "A recording carrying the looked-up ISRC.", + "properties": { + "artistCredit": { + "description": "Credited artist string; falls back to \"Unknown artist\" when none is recorded.", + "type": "string" + }, + "length": { + "description": "Recording length as m:ss. Omitted when unknown.", + "type": "string" + }, + "mbid": { + "description": "Recording MBID — chain to musicbrainz_get_recording.", + "type": "string" + }, + "title": { + "description": "Recording title.", + "type": "string" + } + }, + "required": [ + "mbid", + "title", + "artistCredit" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "recordings" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "ISWC result arm: works carrying the ISWC.", + "properties": { + "identifier": { + "description": "The looked-up identifier value.", + "type": "string" + }, + "kind": { + "const": "works", + "description": "ISWC resolved to works.", + "type": "string" + }, + "works": { + "description": "Works carrying this ISWC.", + "items": { + "additionalProperties": false, + "description": "A work carrying the looked-up ISWC.", + "properties": { + "mbid": { + "description": "Work MBID — chain to musicbrainz_get_work.", + "type": "string" + }, + "title": { + "description": "Work title.", + "type": "string" + }, + "type": { + "description": "Work type. Omitted when absent.", + "type": "string" + } + }, + "required": [ + "mbid", + "title" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "works" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Barcode result arm: releases carrying the barcode.", + "properties": { + "identifier": { + "description": "The barcode digits that were searched (spaces and hyphens removed).", + "type": "string" + }, + "kind": { + "const": "releases", + "description": "Barcode resolved to releases.", + "type": "string" + }, + "releases": { + "description": "Releases carrying this barcode (ranked).", + "items": { + "additionalProperties": false, + "description": "A release carrying the looked-up barcode.", + "properties": { + "artistCredit": { + "description": "Credited artist string.", + "type": "string" + }, + "country": { + "description": "Release country code. Omitted when absent.", + "type": "string" + }, + "date": { + "description": "Release date. Omitted when absent.", + "type": "string" + }, + "mbid": { + "description": "Release MBID — chain to musicbrainz_get_release.", + "type": "string" + }, + "score": { + "description": "Lucene relevance score, 0–100 (barcode is a search filter; exact = 100).", + "type": "number" + }, + "title": { + "description": "Release title.", + "type": "string" + } + }, + "required": [ + "mbid", + "title", + "artistCredit", + "score" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "releases" + ], + "type": "object" + } +]
- Changed
musicbrainz_search_entities3 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"Lucene query string. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported."New value: +"Lucene query string; must contain non-whitespace text. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported. Sent to MusicBrainz exactly as given." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `blank_query`: The query contains only whitespace (it is blank after trimming). Other values are possible when a failure originates below the handler." - added
Output schema / properties / error / properties / data / properties / reason / examplesAdded value: +[ + "blank_query" +]
10 tool updates
- Changed
musicbrainz_browse_entities6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "targetType", + "linkType", + "linkMbid", + "entities", + "offset", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_link`: No link MBID was provided, more than one was provided, or the link MBID is malformed (HTTP 400). `entity_not_found`: The link MBID is well-formed but no such parent entity exists (HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_link", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "targetType", - "linkType", - "linkMbid", - "entities", - "offset", - "totalCount" -]
- Changed
musicbrainz_get_artist6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "name", + "aliases", + "tags", + "releaseGroups", + "relationships", + "externalLinks" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no artist exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "name", - "aliases", - "tags", - "releaseGroups", - "relationships", - "externalLinks" -]
- Changed
musicbrainz_get_cover_art6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "entityType", + "images", + "hasArt" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (the upstream returns HTTP 400). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "entityType", - "images", - "hasArt" -]
- Changed
musicbrainz_get_label6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "name", + "aliases", + "tags", + "externalLinks" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no label exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "name", - "aliases", - "tags", - "externalLinks" -]
- Changed
musicbrainz_get_recording6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "title", + "artistCredit", + "artistCreditString", + "isrcs", + "releases", + "relationships", + "externalLinks" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no recording exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "title", - "artistCredit", - "artistCreditString", - "isrcs", - "releases", - "relationships", - "externalLinks" -]
- Changed
musicbrainz_get_release6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "title", + "artistCredit", + "artistCreditString", + "labelInfo", + "media", + "coverArt" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no release exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "title", - "artistCredit", - "artistCreditString", - "labelInfo", - "media", - "coverArt" -]
- Changed
musicbrainz_get_release_group6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "title", + "artistCredit", + "artistCreditString", + "releases", + "tags", + "coverArt" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no release-group exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "title", - "artistCredit", - "artistCreditString", - "releases", - "tags", - "coverArt" -]
- Changed
musicbrainz_get_work6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "mbid", + "title", + "languages", + "iswcs", + "aliases", + "tags", + "relationships", + "externalLinks" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_mbid`: The MBID is malformed or the all-zeros sentinel (MusicBrainz returns HTTP 400). `entity_not_found`: The MBID is well-formed but no work exists with it (MusicBrainz returns HTTP 404). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_mbid", + "entity_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "mbid", - "title", - "languages", - "iswcs", - "aliases", - "tags", - "relationships", - "externalLinks" -]
- Changed
musicbrainz_lookup_identifier6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "result" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `identifier_not_found`: The identifier is well-formed but resolves to zero entities. `invalid_identifier`: The ISRC/ISWC is malformed (the dedicated endpoint returns HTTP 400). Other values are possible when a failure originates below the handler.", + "examples": [ + "identifier_not_found", + "invalid_identifier" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "result" -]
- Changed
musicbrainz_search_entities6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "entityType", + "results", + "effectiveQuery", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "entityType", - "results", - "effectiveQuery", - "totalCount" -]
3 tool updates
- Changed
musicbrainz_get_release_group5 fields changed- added
Output schema / properties / capAdded value: +{ + "description": "The one-page cap that was applied. Absent when not truncated.", + "type": "number" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "How to fetch the complete list of editions when truncated.", + "type": "string" +} - changed
Output schema / properties / releases / descriptionPrevious value: -"Releases (editions) in this group (may be empty)."New value: +"Releases (editions) in this group (one page; may be empty or capped — use browse for all)." - added
Output schema / properties / shownAdded value: +{ + "description": "Number of releases returned. Absent when not truncated.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when the releases list hit the one-page cap and more editions exist. Absent when the full set fit in one page.", + "type": "boolean" +}
- Changed
musicbrainz_get_work5 fields changed- removed
Output schema / properties / capRemoved value: -{ - "description": "The one-page cap that was applied. Absent when not truncated.", - "type": "number" -} - removed
Output schema / properties / noticeRemoved value: -{ - "description": "How to fetch the complete list of recordings of this work when truncated.", - "type": "string" -} - changed
Output schema / properties / relationships / descriptionPrevious value: -"Writer/composer/lyricist relationships and recording-rels (may be empty; recording-rels capped at one page)."New value: +"Writer/composer/lyricist relationships and recording-rels — the complete set (may be empty)." - removed
Output schema / properties / shownRemoved value: -{ - "description": "Number of recording relationships returned. Absent when not truncated.", - "type": "number" -} - removed
Output schema / properties / truncatedRemoved value: -{ - "description": "True when the recording relationships hit the one-page cap. Absent when the full set fit in one page.", - "type": "boolean" -}
- Changed
musicbrainz_lookup_identifier2 fields changed- changed
Input schema / properties / value / descriptionPrevious value: -"The identifier value. ISRC e.g. \"USRC17607839\"; ISWC e.g. \"T-345246800-1\"; barcode e.g. \"075678164125\"."New value: +"The identifier value. ISRC e.g. \"USRC17607839\"; ISWC e.g. \"T-010.140.236-1\"; barcode e.g. \"075678164125\"." - changed
Output schema / properties / result / oneOfPrevious value: -[ - { - "additionalProperties": false, - "description": "ISRC result arm: recordings carrying the ISRC.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "recordings", - "description": "ISRC resolved to recordings.", - "type": "string" - }, - "recordings": { - "description": "Recordings carrying this ISRC.", - "items": { - "additionalProperties": false, - "description": "A recording carrying the looked-up ISRC.", - "properties": { - "artistCredit": { - "description": "Credited artist string.", - "type": "string" - }, - "length": { - "description": "Recording length as m:ss. Omitted when unknown.", - "type": "string" - }, - "mbid": { - "description": "Recording MBID — chain to musicbrainz_get_recording.", - "type": "string" - }, - "title": { - "description": "Recording title.", - "type": "string" - } - }, - "required": [ - "mbid", - "title", - "artistCredit" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "recordings" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "ISWC result arm: works carrying the ISWC.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "works", - "description": "ISWC resolved to works.", - "type": "string" - }, - "works": { - "description": "Works carrying this ISWC.", - "items": { - "additionalProperties": false, - "description": "A work carrying the looked-up ISWC.", - "properties": { - "mbid": { - "description": "Work MBID — chain to musicbrainz_get_work.", - "type": "string" - }, - "title": { - "description": "Work title.", - "type": "string" - }, - "type": { - "description": "Work type. Omitted when absent.", - "type": "string" - } - }, - "required": [ - "mbid", - "title" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "works" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Barcode result arm: releases carrying the barcode.", - "properties": { - "identifier": { - "description": "The looked-up identifier value.", - "type": "string" - }, - "kind": { - "const": "releases", - "description": "Barcode resolved to releases.", - "type": "string" - }, - "releases": { - "description": "Releases carrying this barcode (ranked).", - "items": { - "additionalProperties": false, - "description": "A release carrying the looked-up barcode.", - "properties": { - "artistCredit": { - "description": "Credited artist string.", - "type": "string" - }, - "country": { - "description": "Release country code. Omitted when absent.", - "type": "string" - }, - "date": { - "description": "Release date. Omitted when absent.", - "type": "string" - }, - "mbid": { - "description": "Release MBID — chain to musicbrainz_get_release.", - "type": "string" - }, - "score": { - "description": "Lucene relevance score, 0–100 (barcode is a search filter; exact = 100).", - "type": "number" - }, - "title": { - "description": "Release title.", - "type": "string" - } - }, - "required": [ - "mbid", - "title", - "artistCredit", - "score" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "kind", - "identifier", - "releases" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "description": "ISRC result arm: recordings carrying the ISRC.", + "properties": { + "identifier": { + "description": "The looked-up identifier value.", + "type": "string" + }, + "kind": { + "const": "recordings", + "description": "ISRC resolved to recordings.", + "type": "string" + }, + "recordings": { + "description": "Recordings carrying this ISRC.", + "items": { + "additionalProperties": false, + "description": "A recording carrying the looked-up ISRC.", + "properties": { + "artistCredit": { + "description": "Credited artist string; falls back to \"Unknown artist\" when none is recorded.", + "type": "string" + }, + "length": { + "description": "Recording length as m:ss. Omitted when unknown.", + "type": "string" + }, + "mbid": { + "description": "Recording MBID — chain to musicbrainz_get_recording.", + "type": "string" + }, + "title": { + "description": "Recording title.", + "type": "string" + } + }, + "required": [ + "mbid", + "title", + "artistCredit" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "recordings" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "ISWC result arm: works carrying the ISWC.", + "properties": { + "identifier": { + "description": "The looked-up identifier value.", + "type": "string" + }, + "kind": { + "const": "works", + "description": "ISWC resolved to works.", + "type": "string" + }, + "works": { + "description": "Works carrying this ISWC.", + "items": { + "additionalProperties": false, + "description": "A work carrying the looked-up ISWC.", + "properties": { + "mbid": { + "description": "Work MBID — chain to musicbrainz_get_work.", + "type": "string" + }, + "title": { + "description": "Work title.", + "type": "string" + }, + "type": { + "description": "Work type. Omitted when absent.", + "type": "string" + } + }, + "required": [ + "mbid", + "title" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "works" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Barcode result arm: releases carrying the barcode.", + "properties": { + "identifier": { + "description": "The looked-up identifier value.", + "type": "string" + }, + "kind": { + "const": "releases", + "description": "Barcode resolved to releases.", + "type": "string" + }, + "releases": { + "description": "Releases carrying this barcode (ranked).", + "items": { + "additionalProperties": false, + "description": "A release carrying the looked-up barcode.", + "properties": { + "artistCredit": { + "description": "Credited artist string.", + "type": "string" + }, + "country": { + "description": "Release country code. Omitted when absent.", + "type": "string" + }, + "date": { + "description": "Release date. Omitted when absent.", + "type": "string" + }, + "mbid": { + "description": "Release MBID — chain to musicbrainz_get_release.", + "type": "string" + }, + "score": { + "description": "Lucene relevance score, 0–100 (barcode is a search filter; exact = 100).", + "type": "number" + }, + "title": { + "description": "Release title.", + "type": "string" + } + }, + "required": [ + "mbid", + "title", + "artistCredit", + "score" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "kind", + "identifier", + "releases" + ], + "type": "object" + } +]
10 tool updates
- First observed
musicbrainz_browse_entities - First observed
musicbrainz_get_artist - First observed
musicbrainz_get_cover_art - First observed
musicbrainz_get_label - First observed
musicbrainz_get_recording - First observed
musicbrainz_get_release - First observed
musicbrainz_get_release_group - First observed
musicbrainz_get_work - First observed
musicbrainz_lookup_identifier - First observed
musicbrainz_search_entities
Related MCP Connectors
MusicBrainz MCP — wraps MusicBrainz Web Service v2 (free, no auth)
Search books and authors, fetch editions, browse subjects, and resolve cover images.
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Search, analyze, and discover commercially released music using sonic intelligence.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables searching music artists and releases, and retrieving artist biographies, discographies, release track listings, credits, and metadata through the MusicBrainz API.1 npmMIT
- AlicenseAqualityDmaintenanceEnables AI assistants to query the MusicBrainz music database for artists, albums, recordings, and labels. It provides tools for advanced searches, detailed metadata retrieval, and accessing cover art information.1713GPL 3.0
- AlicenseAqualityAmaintenanceAn MCP server that provides live access to MusicBrainz metadata and Cover Art Archive images, with optional OAuth-based submission of tags, ratings, and collection edits.9720 npmMIT
- FlicenseNot gradedqualityCmaintenanceEnables music search, metadata retrieval, local audio analysis (tempo, key, energy), recommendations, song recognition, and classical work resolution via Spotify, Last.fm, AudD, MusicBrainz, and Songkick APIs.-
Glama MCP Gateway
Add one secure layer between your agents and this server.