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
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?
The description adds behavioral details beyond annotations: 'Pages arbitrarily deep via offset; totalCount is the true upstream total.' Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, so the description adds value without 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?
Two sentences front-load the key purpose and distinguish from siblings. Every sentence is informative and concise, with no redundancy.
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 (4 params, 100% schema coverage, output schema exists), the description covers pagination, parent-child relationships, usage guidance, and behavioral transparency. It is complete for an agent to select and invoke correctly.
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%, baseline 3. The description adds semantic meaning: 'Paginate the COMPLETE set', 'Provide exactly ONE link MBID matching a valid parent→child relationship for the target_type', and explains the relationship between link and target_type. This elevates the score above baseline.
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 enumerates the complete set of entities linked to a parent MBID, contrasting with get_* tools that only return one page. It specifies the verb 'browse', the resource 'entities linked to a parent MBID', and distinguishes from siblings by highlighting the pagination limitation of 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 explicitly states when to 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)'. It also instructs to 'Provide exactly ONE link MBID matching a valid parent→child relationship', and implies alternatives are the get_* tools.
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?
Beyond annotations (readOnlyHint, idempotentHint), description adds useful behavioral details: caps at one page (25) for discography and relationships, and that external links are surfaced as 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?
Description is dense but clear, with a front-loaded summary and specific details. Could be slightly more concise but effectively communicates key points in a few sentences.
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 adequately covers what to expect (fields, caps, relationships) and provides context for using the tool effectively in a workflow, referencing sibling tools where needed.
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. Description adds meaning by explaining the effect of inc_release_groups and inc_relationships (e.g., band-membership, external links, caps), enriching the schema documentation.
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 it retrieves an artist profile by MBID, enumerates included fields (type, country, life span, etc.), and explicitly calls it 'the 80% artist-detail call', 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?
Provides explicit guidance on when to use this tool (for typical artist detail) and when to use an alternative (musicbrainz_browse_entities for complete release lists of prolific artists), including specific parameters like target_type=release-group.
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 declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: resolution of release-group MBIDs to a representative release, empty set on no art, and copyright attribution (URLs not rehosted). This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds distinct value: purpose, behavior on no art, resolution logic, and copyright note. No unnecessary 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's simplicity and the presence of an output schema, the description covers all necessary context: input types, output contents (front/back, thumbnails), behavior for missing art, and legal notes. It is complete for the agent to understand usage and expectations.
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 baseline is 3. The description does not add any parameter-specific information beyond what the schema provides; it instead focuses on output structure. Thus, it meets the baseline but does not exceed 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 Cover Art Archive images for a release or release-group MBID, specifying the verb 'get' and the resource 'cover art'. It distinguishes itself from sibling tools by focusing exclusively on cover art, which no other sibling does.
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 clear context: it handles both release and release-group MBIDs, and notes that absence of art returns an empty set (not an error). However, it does not explicitly compare to alternatives or state when not to use this tool, though siblings are sufficiently different to imply distinct usage.
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?
While annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds critical behavioral context: it explicitly states that releases are not included and explains why (potentially huge linked set). This goes beyond the annotations and prevents erroneous assumptions about the tool's output scope.
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 remarkably concise, consisting of two sentences that convey all necessary information. The first sentence lists the returned fields, and the second explains the exclusion of releases and points to the sibling tool. Every sentence adds value with no redundancy.
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 moderate complexity (returning multiple fields) and the presence of an output schema (which presumably details the return structure), the description is complete. It covers what the tool returns, what it does not return, and how to access the missing data, leaving no critical gaps.
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 has 100% description coverage for the single parameter 'mbid', describing it as 'Label MBID (36-character UUID).' The description does not add any additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed 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's purpose: fetching a label by MBID, and lists the specific fields returned (type, country, etc.). It also distinguishes itself from the sibling tool musicbrainz_browse_entities by explicitly noting that releases are not embedded, which prevents confusion.
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 metadata) and when to use an alternative (use musicbrainz_browse_entities for releases). It also warns about the large size of release sets, helping the agent make informed decisions.
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 behavior. Description adds that relationships are capped at one page, which is a key behavioral trait not covered by annotations. This provides valuable context beyond structured fields.
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 well-structured sentences with key information front-loaded. Every sentence adds value: first defines the tool's purpose and output, second provides pagination and alternative usage guidance. 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?
Covers all essential aspects: output contents, pagination behavior, chaining to related tools, and when to use a sibling tool. With an output schema present, the description is sufficient and does not need to detail return format further.
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 already describes both parameters (mbid as UUID, inc_relationships as boolean with a brief description). The description adds minimal new parameter-specific meaning; it mostly elaborates on the output structure. Since schema coverage is 100%, baseline is 3, and description does not significantly enhance parameter understanding.
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 the tool returns recording details by MBID, including length, credits, ISRCs, releases, works, and relationships. It distinguishes from siblings by specifying when to chain to musicbrainz_get_work and when to use musicbrainz_browse_entities for pagination.
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 advises using musicbrainz_browse_entities when relationships exceed one page, and directs chaining to musicbrainz_get_work for work details. Provides clear context for when the tool is sufficient and when alternatives are needed.
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 declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral details such as track lengths converted to m:ss format and that cover-art availability is just a stub. 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 a single, well-organized paragraph that front-loads the main purpose, lists contents efficiently, and ends with a clear cross-reference. Every sentence serves a purpose without redundancy.
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 single parameter and presence of output schema, the description covers all necessary context: what data is returned, how track lengths are formatted, and a link to the sibling tool for cover art. No gaps.
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 provides a full description of the mbid parameter (36-character UUID) with 100% coverage. The description adds no additional constraint or context beyond mentioning 'by MBID', so baseline score applies.
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 full details of one edition by MBID, listing specific fields (tracklist, label, barcode, etc.). It distinguishes from siblings like musicbrainz_get_cover_art by noting that this tool only provides a cover-art stub, not actual 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?
The description explicitly directs the agent to musicbrainz_get_cover_art for actual cover images, providing clear guidance on when not to use this tool. However, it does not contrast with every sibling, though the entity-specific nature makes usage clear.
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). 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 |
|---|---|---|
| mbid | Yes | Release-group MBID. |
| tags | Yes | Community tags/genres (may be empty). |
| title | Yes | Release-group title. |
| coverArt | Yes | Whether cover art exists (availability stub from WS/2). |
| releases | Yes | Releases (editions) in this group (may be empty). |
| 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 read-only, open-world, idempotent behavior. Description adds details on which WS/2 payload fields are returned (primary/secondary types, first-release date, artist credit, releases list, tags/genres, cover-art flag). 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?
Description is one sentence but packs in many details; could be slightly restructured for readability, but 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 presence of an output schema (stated true) and rich annotations, the description provides adequate context about what the tool returns and how it fits with sibling tools. Complete enough for an agent to use correctly.
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 covers 100% of parameters with a clear description of the single required 'mbid' parameter. Description does not add further semantics beyond what the schema already provides, so baseline of 3 applies.
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 it retrieves release group by MBID, listing included fields (type, dates, artist, releases, tags, cover-art flag). Distinguishes from siblings by directing to other tools for cover art URLs and tracklists.
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 to use this for the 'album' above pressings and advises using musicbrainz_get_cover_art for image URLs and musicbrainz_get_release for per-edition tracklists. Could add when-not-to-use but is clear enough.
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. Recording relations are capped at one page; for the complete list of recordings of a work, call musicbrainz_browse_entities with target_type=recording and link.work.
| 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 |
|---|---|---|
| cap | No | The one-page cap that was applied. Absent when not truncated. |
| 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). |
| shown | No | Number of recording relationships returned. Absent when not truncated. |
| title | Yes | Work title. |
| notice | No | How to fetch the complete list of recordings of this work when truncated. |
| aliases | Yes | Alternate titles (may be empty). |
| languages | Yes | Lyrics languages (ISO codes; may be empty). |
| truncated | No | True when the recording relationships hit the one-page cap. Absent when the full set fit in one page. |
| externalLinks | Yes | External resource links (url-rels) (may be empty). |
| relationships | Yes | Writer/composer/lyricist relationships and recording-rels (may be empty; recording-rels capped at one page). |
| disambiguation | No | Short qualifier. Omitted when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. Description adds the behavioral trait that recording relations are paginated and capped, which is not in annotations. 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?
Two sentences, dense with information, no wasted words. Could be slightly more structured but remains clear.
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 all returned data types, includes limitation on recordings, and directs to sibling tool. Output schema exists, so return values are already documented.
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. Description does not add extra parameter details beyond what schema provides, but overall context is sufficient.
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 work details by MBID, including type, language, ISWCs, relationships, aliases, tags, and recordings. It distinguishes this from specific recordings, differentiating it from siblings like musicbrainz_get_recording.
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 notes that recording relations are capped at one page and directs users to musicbrainz_browse_entities for the complete list, providing clear when-to-use and alternative guidance.
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-345246800-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?
Annotations already provide readOnly, idempotent, and openWorld hints. Description adds behavioral details: ISRC/ISWC hit dedicated exact endpoints, barcode uses Lucene search with ranked results, and mentions the 'kind' field in output.
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 concise sentences, front-loaded with purpose, each sentence adds unique value with no redundancy.
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 2-parameter tool with comprehensive annotations and an existing output schema, the description fully covers input behavior, endpoint differences, and result interpretation. 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 covers both parameters fully. Description adds semantic value: explains what each id_type maps to, provides example formats, and notes barcode's ranking behavior (exact match scores 100).
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 resolves standard identifiers to MusicBrainz entities deterministically without name search. It distinguishes from sibling tools like musicbrainz_search_entities by emphasizing this as the 'deterministic path when you already hold an ID.'
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 states when to use ('when you already hold an ID') and maps identifier types to entity types. Does not explicitly state when not to use, but context implies alternatives (search) for missing IDs.
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 readOnlyHint, openWorldHint, and idempotentHint. The description adds that results are ordered by MusicBrainz score descending and supports Lucene field-scoped syntax, providing behavioral detail beyond the annotations. 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?
Concise, with no extraneous sentences. Front-loaded with purpose and key details, well-structured for agent consumption.
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 search tool with annotations, output schema, and four parameters, the description covers essential aspects: entity types, query syntax, result fields, ordering, and chaining to get tools. It is complete for an agent to decide when and how to use 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%. The description reinforces parameter meaning (e.g., 'Plain text matches names/titles; field scoping is supported') and adds examples like 'artist:radiohead AND country:GB', adding value beyond the schema definitions.
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 does full-text search across MusicBrainz entity types using a Lucene query string, listing the exact entity types and the return fields (MBID, name, disambiguation, type, relevance score). It distinguishes itself from sibling tools like browse, get, and lookup.
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 states this is the 'starting point when resolving a name to an MBID' and instructs to 'chain the returned MBID into the matching musicbrainz_get_* tool'. Does not mention when not to use, but the context is clear enough.
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!