Skip to main content
Glama

musicbrainz-mcp-server

by io.github.cyanheads

musicbrainz-mcp-server: browse entities

musicbrainz_browse_entities
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkYesExactly one parent MBID. The valid key depends on target_type (see the description).
limitNoPage size (1–100).
offsetNoResult offset for deep pagination (0-based).
target_typeYesThe entity type to enumerate (the children).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe page size that was applied. Absent when not truncated.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of entities returned in this page. Absent when not truncated.
noticeNoHow to page further when results remain, or guidance when empty.
offsetNoThe offset used for this page.
entitiesNoThis page of linked entities, in upstream order.
linkMbidNoThe parent MBID that was browsed.
linkTypeNoThe parent link type used (artist, label, release-group, recording, work, or area).
truncatedNoTrue when more entities remain beyond this page (offset + shown < totalCount). Absent when the page is complete.
targetTypeNoThe entity type that was enumerated.
totalCountNoTrue total number of linked entities upstream (the {type}-count field).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already signal read-only, open-world, and idempotent behavior; the description adds valuable operational details like deep pagination via offset, totalCount as the true upstream total, and the exact-one-link requirement. Nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then moves directly to when to use it, constraints, and pagination behavior. Every sentence contributes meaningful guidance with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a moderately complex tool with nested link objects, enums, and pagination; the description provides enough context to use it effectively and safely. The output schema and detailed annotations fill in the remaining structured details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, and the main description strengthens understanding by requiring exactly one link MBID and clarifying parent-child relationships. Offset and limit semantics are also explained beyond their schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action—paginate the COMPLETE set of entities linked to a parent MBID—and gives concrete examples across target types. It also differentiates itself from the get_* siblings by explicitly being the only complete-enumeration path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit when-to-use rule: whenever a linked set may exceed the single 25-item page returned by get_* tools. It also states the main constraint—exactly one link MBID and a valid parent-child relationship—which helps prevent incorrect invocations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All musicbrainz-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct purpose: browsing for paginated lists, getting individual entities, resolving identifiers, and text search. No overlap in functionality.

Naming Consistency5/5

All tools follow the musicbrainz_ prefix with clear verb-noun patterns (browse_entities, get_artist, lookup_identifier, search_entities), providing a consistent and predictable interface.

Tool Count5/5

With 10 tools covering all core MusicBrainz entity types, pagination, identifier resolution, and search, the count is well-scoped for a comprehensive API without being excessive.

Completeness5/5

The set covers all primary entity types (artist, label, recording, release, release-group, work), plus browsing, searching, identifier lookup, and cover art—providing a complete surface for MusicBrainz operations.

Resources