musicbrainz-mcp-server
Server Details
Search MusicBrainz artists, releases, works, labels; resolve ISRC/ISWC/barcode; fetch cover art.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/musicbrainz-mcp-server
- GitHub Stars
- 1
- Server Listing
- musicbrainz-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 10 of 10 tools scored.
Each tool targets a distinct entity or operation (artist, label, release, etc.). No two tools have overlapping purposes; even browse_entities and get_* tools are clearly differentiated as paginated vs. single-page views.
All tools follow a consistent `musicbrainz_<verb>_<entity>` pattern with snake_case. Verbs are descriptive (get, browse, search, lookup) and nouns match entity types, making the naming predictable and easy to parse.
10 tools is ideal for a music metadata API. The count covers all major entities and operations without being overwhelming. Each tool serves a clear, justified purpose.
The tool surface comprehensively covers MusicBrainz querying: core entities (artist, label, recording, release, release-group, work), search, identifier resolution, and cover art retrieval. The browse_entities tool fills enumeration gaps, and all workflows are supported without dead ends.
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. |
| 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 | Yes | The offset used for this page. |
| entities | Yes | This page of linked entities, in upstream order. |
| linkMbid | Yes | The parent MBID that was browsed. |
| linkType | Yes | 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 | Yes | The entity type that was enumerated. |
| totalCount | Yes | True total number of linked entities upstream (the {type}-count field). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context about pagination: 'Pages arbitrarily deep via offset; totalCount is the true upstream total.' This clarifies behavior beyond annotations. A score of 4 reflects good addition without being exhaustive.
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, well-structured paragraph. It front-loads the purpose, then contrasts with siblings, then states the constraint, and ends with pagination details. Every sentence adds value with no redundancy. Excellent conciseness.
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 complexity (4 params, nested objects, output schema exists), the description covers all essentials: what it does, when to use, how to use (one link, pagination), and key behaviors. It does not need to explain the output schema as it exists separately. Complete for effective agent usage.
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%, so baseline is 3. The description adds meaning by stating 'Provide exactly ONE link MBID' and explaining the parent-child relationship, which reinforces the one-of constraint and clarifies valid combinations. This extra guidance justifies a 4.
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 paginates the complete set of entities linked to a parent MBID, using specific verbs (paginate, enumerate) and resource (entities linked to parent MBID). It explicitly distinguishes from sibling get_* tools by noting they embed at most one page, making the tool's unique value clear.
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 guidance on when to use: 'whenever a linked set may exceed a page', with concrete examples ('prolific artist, major label with thousands of releases'). It also states the constraint 'provide exactly one link MBID' and implies the alternative of using get_* for smaller sets. This fully satisfies the dimension.
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 | Yes | Artist MBID. |
| name | Yes | Artist name. |
| tags | Yes | Community tags/genres with vote counts (may be empty). |
| type | No | Artist type (Person, Group, Orchestra, …). Omitted when unknown. |
| 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 | Yes | 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 | Yes | External resource links (url-rels) — Wikidata, Discogs, official site (may be empty). |
| relationships | Yes | Band membership and collaboration relationships (may be empty). |
| releaseGroups | Yes | Discography — release-groups (one page; may be empty or capped). |
| disambiguation | No | Short qualifier distinguishing same-named artists. Omitted when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context: caps on discography and relationships (25 per page), and how external links are surfaced (url-rels). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no wasted words. The main purpose is front-loaded, followed by inclusions and a clear usage note. Highly efficient.
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 complexity of the tool (multiple sections, caps, relationships, external links), the description covers all key aspects. The output schema exists for return details, so the description need not restate them. It also implicitly provides context about pagination and link resolution.
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?
All 3 parameters have schema descriptions (100% coverage). The description adds useful context: 'capped at one page; use browse for the full set' for inc_release_groups and mentions relationships for inc_relationships. This is additive but not essential given schema 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 the tool retrieves an artist profile by MBID, listing specific fields (type, country, life span, gender, area, aliases, tags, genres, discography, relationships, external links). It distinguishes from sibling tools like musicbrainz_browse_entities by explicitly mentioning usage for full release-group lists.
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 guidance: 'The 80% artist-detail call' and advises when to use browse_entities for complete release-group lists. It also notes caps at 25 per section, helping the agent decide when this tool is sufficient.
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. 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 | Yes | The MBID that was queried. |
| hasArt | Yes | Whether any cover art exists for this entity. |
| images | Yes | Cover-art images (empty when the entity has no art). |
| notice | No | Notice when no art exists for the entity. |
| entityType | Yes | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: no error on missing art, resolution of release-group to a release, and copyright information. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: overview, empty set behavior, resolution, and copyright. No redundant or extraneous content. Efficient and front-loaded.
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, the description covers all essential aspects: what the tool returns, behavior when no art exists, entity type resolution, and licensing. No obvious gaps remain.
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 each parameter described in the schema. The description rephrases the parameter types (MBID, entity_type) but does not add significant new meaning beyond the schema. Baseline score of 3 is appropriate.
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 specifies the tool retrieves Cover Art Archive images for a release or release-group MBID, listing specific outputs (front/back flags, image types, URLs). It distinguishes from sibling tools like musicbrainz_get_release by focusing solely on cover art.
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 explains when to use this tool, including that a release-group MBID resolves to a representative release, and that an empty set is returned when no art exists. It does not explicitly state when not to use it or compare with alternatives, but the context is clear.
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 | Yes | Label MBID. |
| name | Yes | Label name. |
| tags | Yes | Community tags/genres (may be empty). |
| type | No | Label type. Omitted when unknown. |
| aliases | Yes | 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 | Yes | External resource links (url-rels) (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context by explaining that releases are not embedded due to size and directing to an alternative, without contradicting 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 concise, front-loaded with the purpose, and every sentence adds value. It uses a colon to list attributes and a clear note about missing releases, with no wasted words.
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 has output schema (not shown but present), the description covers all relevant aspects: return fields, limitations, and cross-reference to sibling tool. It is complete for a single-MBID 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?
There is only one parameter with 100% schema description coverage. The description does not add additional meaning beyond what the schema already provides for 'mbid' (Label MBID, 36-character UUID), so the baseline score of 3 is appropriate.
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 returns label metadata by MBID, listing specific fields (type, country, etc.) and explicitly notes that releases are not included, distinguishing it from sibling tools like musicbrainz_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 provides explicit guidance on when to use this tool (to get label details) and when to use a sibling tool (for releases), with a direct reference to musicbrainz_browse_entities with parameters.
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 | Yes | Recording MBID. |
| isrcs | Yes | ISRCs assigned to this recording (may be empty). |
| title | Yes | Recording title. |
| length | No | Recording length as m:ss. Omitted when unknown. |
| releases | Yes | Releases this recording appears on (may be empty). |
| artistCredit | Yes | Credited artists (may be empty). |
| externalLinks | Yes | External resource links (url-rels) (may be empty). |
| relationships | Yes | 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 | Yes | Display string of the artist credit with join phrases. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent. The description adds a key behavioral detail: 'Relationships are capped at one page; for a heavily-covered recording call musicbrainz_browse_entities with target_type=recording and link.work.' This warns about a limitation beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with dense, useful information. No wasted words; every phrase earns its place.
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 has an output schema, the description needn't explain return values. It covers purpose, parameters, relationships to siblings, and a usage caveat. The definition is complete for a two-parameter 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 coverage is 100%, so baseline is 3. The description adds value by explaining that inc_relationships includes performance/production relationships and work-rels, complementing the schema's terse description.
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 identifies the tool as retrieving a recording by MBID, listing included fields (length, artist credits, ISRCs, releases, works, relationships). It distinguishes from siblings by explicitly mentioning chaining to musicbrainz_get_work and using musicbrainz_browse_entities for more relationships.
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?
Provides explicit guidance: use for a specific recording, chain to musicbrainz_get_work for works, and for heavily-covered recordings use musicbrainz_browse_entities. Clear context and alternatives are given.
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 | Yes | Release MBID. |
| media | Yes | Media (discs) with their tracklists (may be empty). |
| title | Yes | 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 | Yes | Whether cover art exists (availability stub from WS/2). |
| language | No | Text-representation language code. Omitted when absent. |
| labelInfo | Yes | Label / catalog-number pairings (may be empty). |
| packaging | No | Packaging type (Jewel Case, Digipak, …). Omitted when absent. |
| artistCredit | Yes | 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 | Yes | Display string of the artist credit with join phrases. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, safe, idempotent. The description adds that track lengths are rendered as m:ss but stored as milliseconds upstream, and that it returns a cover-art availability stub, not images. This provides useful context beyond 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?
Three sentences, front-loaded with purpose. Each sentence adds value. Could be slightly more structured with bullet lists, but is acceptably concise.
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 an output schema exists, description covers all essential aspects: tracklist, label, barcode, etc., plus unit conversion and cover-art guidance. No gaps identified.
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% (single parameter 'mbid' with description). The description does not add new parameter semantics beyond confirming it's a release MBID. Baseline 3 is appropriate.
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 returns 'One edition's full detail by MBID' and lists specific fields (tracklist, label, catalog number, etc.). It also distinguishes from sibling tool musicbrainz_get_cover_art by directing to that tool for actual cover images.
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 tells when to use: to get full release detail. Provides when-not-to-use: 'For the actual cover image URLs, call musicbrainz_get_cover_art' – a clear alternative.
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 a cover-art availability flag from the WS/2 payload (use musicbrainz_get_cover_art for actual 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 | Yes | Release-group MBID. |
| tags | Yes | Community tags/genres (may be empty). |
| shown | No | Number of releases returned. Absent when not truncated. |
| title | Yes | Release-group title. |
| notice | No | How to fetch the complete list of editions when truncated. |
| coverArt | Yes | Whether cover art exists (availability stub from WS/2). |
| releases | Yes | 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 | Yes | 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 | Yes | Display string of the artist credit with join phrases. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: the embedded releases list is capped at 25, the cover-art availability flag is present but actual images require another tool. Does not contradict 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 well-structured and front-loaded with the main purpose. Every sentence adds value, but it is moderately long (three sentences). Little to no waste, but could be slightly more concise.
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 simple tool (one parameter, clear annotations, output schema exists), the description fully explains what is returned and how to obtain related information (cover art, full edition list, tracklist). No gaps identified.
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% for the single parameter 'mbid' (described as UUID). The description does not add meaning beyond what the schema provides, so baseline 3 is appropriate.
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 verb 'get' and the resource 'release group by MBID'. It enumerates the data returned (primary/secondary types, first-release date, artist credit, releases, tags, cover-art flag) and distinguishes from siblings like musicbrainz_get_release and musicbrainz_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?
Explicitly provides when-to-use (to get release group details) and when-not (for cover art images, full edition list, tracklists). Names alternative tools and parameters (musicbrainz_get_cover_art, musicbrainz_browse_entities with link.release-group, musicbrainz_get_release).
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 | Yes | Work MBID. |
| tags | Yes | Community tags/genres (may be empty). |
| type | No | Work type (Song, Symphony, …). Omitted when unknown. |
| iswcs | Yes | ISWCs assigned to this work (may be empty). |
| title | Yes | Work title. |
| aliases | Yes | Alternate titles (may be empty). |
| languages | Yes | Lyrics languages (ISO codes; may be empty). |
| externalLinks | Yes | External resource links (url-rels) (may be empty). |
| relationships | Yes | Writer/composer/lyricist relationships and recording-rels — the complete set (may be empty). |
| disambiguation | No | Short qualifier. Omitted when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context: recording relationships are returned in full (no paging), and lists all returned data categories, which goes beyond 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 paragraph that efficiently defines the entity and enumerates returned data. Each sentence is informative, with no redundancy or fluff. The structure is front-loaded with the definition of work.
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 complexity of the work entity, the 100% schema coverage, output schema existence, and annotations, the description fully informs about the tool's behavior. It explains what a work is, what data is returned, and the notable fact about recording relationships not being paged.
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 descriptions for both parameters. The description adds minimal extra meaning: it clarifies that inc_relationships includes writer/composer relationships, recording relationships, and external links, which is similar to the schema description. No significant addition 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?
Describes the tool as retrieving a work (composition) by MBID, listing specific data fields (type, language, ISWCs, relationships, aliases, tags, recordings). Clearly distinguishes from sibling tools like get_artist or get_recording by focusing on work-specific attributes and the uniqueness of recording relationships not being paged.
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 implies usage when work details are needed, but does not explicitly contrast with other tools like search_entities or browse_entities. However, the sibling tools' names and the tool's specific purpose make it clear when to choose this tool over others.
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). 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 e.g. "075678164125". | |
| id_type | Yes | Which standard identifier: isrc (recording), iswc (work), or barcode (release). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | The resolved entities, discriminated by `kind` (recordings | works | releases). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), it explains endpoint behavior: ISRC/ISWC hit dedicated exact endpoints, barcode uses Lucene search with ranking, and results include a 'kind' field indicating 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?
One dense paragraph with no wasted words. Front-loaded with purpose, followed by id_type-specific details and output behavior. Every sentence adds essential information.
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, the description covers all necessary aspects: id_type-specific mappings, endpoint behavior, and result ranking. No gaps for correct tool invocation.
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%, but description adds value with identifier examples (ISRC, ISWC formats, barcode as UPC/EAN) and behavioral differences per id_type. This exceeds what the schema provides.
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 resolves standard identifiers to MusicBrainz entities without name search, distinguishing it from sibling tools like musicbrainz_search_entities. It explicitly calls out the deterministic path for known IDs.
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 specifies when to use (when you already hold an ID) and contrasts with name search. It could mention alternatives like browse or get endpoints, but the context is clear enough for decision-making.
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. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported. | |
| offset | No | Result offset for pagination (0-based). | |
| entityType | Yes | Which entity type to search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when zero results matched — how to broaden or correct the query. |
| results | Yes | Ranked matches, in MusicBrainz score-descending order. |
| entityType | Yes | The entity type that was searched. |
| totalCount | Yes | Total matches upstream before the limit/offset window. |
| effectiveQuery | Yes | The query string as sent to MusicBrainz. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent hints. Description adds Lucene syntax support, score-descending order, and relevance scoring. No contradictions. Could mention rate limits but omission is minor given annotation coverage.
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?
Description is compact (4 sentences), front-loaded with core purpose, each sentence adds value. Could be slightly more structured but overall efficient.
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?
Covers purpose, usage context, return fields, and chaining. Output schema exists to handle detailed return structure. Lacks error/empty result handling but acceptable given tool simplicity.
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% so baseline 3 is appropriate. Description reinforces entityType and query semantics (Lucene string, field scoping) but adds little beyond schema. No compensation needed.
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?
Description clearly states full-text search across MusicBrainz entity types using Lucene query, specifies returned fields (MBID, name/title, disambiguation, type, relevance score). Distinguishes from sibling get tools by positioning as starting point for name-to-MBID resolution.
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 says 'Starting point when resolving a name to an MBID' and directs to chain MBID into get tools. Lacks explicit comparison to sibling browse tool, but context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.