When to use this skill
When the user has a MusicBrainz ID (MBID) or an ISRC code and wants to look up the specific entity it identifies — an artist, release, recording, label, or work — with full metadata and relationships. This is the "I already know the identifier" path, not the search path. For finding entities by name or keyword when you don't have an MBID, use the MusicBrainz search skill instead.
Your best first call
curl "https://musicbrainz.org/ws/2/artist/056e4f3e-d505-4dad-8ec1-d04f521cbb56?fmt=json&inc=artist-rels+tags+ratings"
No auth. No key. But MusicBrainz requires a User-Agent header identifying your application — IPs that omit it get blocked. The inc= parameter is what turns a bare lookup (name, country, lifespan) into a rich one: artist-rels brings in band membership with instrument credits, tags adds crowd-sourced genres, ratings adds community scores. Replace artist in the path with release, recording, label, work, or any other entity type — the MBID is always the path segment after the entity type.
The response shape is consistent across entity types. The key fields an agent uses:
id — the MBID (opaque UUID; you cannot derive it from a name)
name, sort-name — display name and sorted form
disambiguation — parenthetical that distinguishes same-name entities (e.g. "French electronic duo" for Daft Punk, "1980s-1990s US grunge band" for Nirvana)
type — "Group" or "Person" for artists; analogous type fields exist for other entities
life-span — {begin, end, ended} covering the entity's active period
relations — array of typed relationships, each carrying type, artist (or the related entity), attributes (e.g. instrument credits), and date ranges
tags — {name, count} objects representing community-voted genre labels
For ISRC resolution (when you have a 12-character recording code, not an MBID), use /ws/2/isrc/{isrc}?fmt=json — it returns a recordings array with title, length, and MBID for each matching mastering.
Fallbacks (when the best first call isn't enough)
- You don't have the MBID yet → search first with
/ws/2/{entity}?query=…&fmt=json&limit=10, then use the MBID from results for a lookup with inc=. The search endpoint is a separate skill.
- You need browse-style navigation (all releases by an artist) →
/ws/2/release?artist={mbid}&fmt=json returns paged results linked to a known entity, no search query needed.
Pitfalls
fmt=json is not optional. Omit it and MusicBrainz returns XML — angle brackets, not curly braces. Every lookup must include it.
- MBIDs are opaque UUIDs, not constructable. You cannot derive an artist's MBID from their name — you must search first or receive it from another source. Calling
/artist/{made-up-uuid} returns 404, not an empty result.
- Rate limit is 1 request per second. MusicBrainz enforces this strictly and blocks IPs that exceed it. Include a descriptive
User-Agent header with a contact URL or email. Batch lookups must be paced.
disambiguation can be empty but is never wrong. When multiple artists share a name, the disambiguation field is what separates them. An empty string means the entity is unambiguous in context — do not treat it as missing data.
One-line summary for the user
I can look up a specific MusicBrainz entity — artist, release, recording, or work — by its MBID or ISRC code, returning full metadata and relationships in a single unauthenticated JSON request, but you need the identifier first since MBIDs are opaque UUIDs you can't derive from a name.
SKILL.md source (frontmatter + body)
---
name: access-separate
description: When the user has a MusicBrainz MBID or ISRC code and wants to look up the specific artist, release, recording, or work it identifies — with metadata, relationships, and tags — reach for MusicBrainz lookup. Separate entity access by identifier, not search.
---
## When to use this skill
When the user has a MusicBrainz ID (MBID) or an ISRC code and wants to look up the specific entity it identifies — an artist, release, recording, label, or work — with full metadata and relationships. This is the "I already know the identifier" path, not the search path. For finding entities by name or keyword when you don't have an MBID, use the MusicBrainz search skill instead.
## Your best first call
```bash
curl "https://musicbrainz.org/ws/2/artist/056e4f3e-d505-4dad-8ec1-d04f521cbb56?fmt=json&inc=artist-rels+tags+ratings"
```
No auth. No key. But MusicBrainz requires a `User-Agent` header identifying your application — IPs that omit it get blocked. The `inc=` parameter is what turns a bare lookup (name, country, lifespan) into a rich one: `artist-rels` brings in band membership with instrument credits, `tags` adds crowd-sourced genres, `ratings` adds community scores. Replace `artist` in the path with `release`, `recording`, `label`, `work`, or any other entity type — the MBID is always the path segment after the entity type.
The response shape is consistent across entity types. The key fields an agent uses:
- `id` — the MBID (opaque UUID; you cannot derive it from a name)
- `name`, `sort-name` — display name and sorted form
- `disambiguation` — parenthetical that distinguishes same-name entities (e.g. "French electronic duo" for Daft Punk, "1980s-1990s US grunge band" for Nirvana)
- `type` — "Group" or "Person" for artists; analogous type fields exist for other entities
- `life-span` — `{begin, end, ended}` covering the entity's active period
- `relations` — array of typed relationships, each carrying `type`, `artist` (or the related entity), `attributes` (e.g. instrument credits), and date ranges
- `tags` — `{name, count}` objects representing community-voted genre labels
For ISRC resolution (when you have a 12-character recording code, not an MBID), use `/ws/2/isrc/{isrc}?fmt=json` — it returns a `recordings` array with title, length, and MBID for each matching mastering.
## Fallbacks (when the best first call isn't enough)
- **You don't have the MBID yet** → search first with `/ws/2/{entity}?query=…&fmt=json&limit=10`, then use the MBID from results for a lookup with `inc=`. The search endpoint is a separate skill.
- **You need browse-style navigation (all releases by an artist)** → `/ws/2/release?artist={mbid}&fmt=json` returns paged results linked to a known entity, no search query needed.
## Pitfalls
- **`fmt=json` is not optional.** Omit it and MusicBrainz returns XML — angle brackets, not curly braces. Every lookup must include it.
- **MBIDs are opaque UUIDs, not constructable.** You cannot derive an artist's MBID from their name — you must search first or receive it from another source. Calling `/artist/{made-up-uuid}` returns 404, not an empty result.
- **Rate limit is 1 request per second.** MusicBrainz enforces this strictly and blocks IPs that exceed it. Include a descriptive `User-Agent` header with a contact URL or email. Batch lookups must be paced.
- **`disambiguation` can be empty but is never wrong.** When multiple artists share a name, the `disambiguation` field is what separates them. An empty string means the entity is unambiguous in context — do not treat it as missing data.
## One-line summary for the user
I can look up a specific MusicBrainz entity — artist, release, recording, or work — by its MBID or ISRC code, returning full metadata and relationships in a single unauthenticated JSON request, but you need the identifier first since MBIDs are opaque UUIDs you can't derive from a name.