Skip to main content
Glama

musicbrainz-mcp-server: search entities

musicbrainz_search_entities
Read-onlyIdempotent

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, subtype where applicable, release status, and a 0–100 relevance score (100 = exact). Release rows use status; other entity subtypes use type. 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).

Input Schema

NameRequiredDescriptionDefault
limitNoPositive integer page size (default 25); values above 100 are clamped to 100 with a notice. With MUSICBRAINZ_CLAMP_OVERSIZED_LIMITS=off, maximum 100 is enforced.
queryYesLucene query string; must contain non-whitespace text. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported. Sent to MusicBrainz exactly as given.
offsetNoResult offset for pagination (0-based).
entityTypeYesWhich entity type to search.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoLimit clamp and pagination guidance, including zero matches, exhausted pages, and empty-page discrepancies.
offsetNoThe effective zero-based result offset used for this page.
resultsNoRanked matches, in MusicBrainz score-descending order.
entityTypeNoThe entity type that was searched.
totalCountNoTotal matches upstream before the limit/offset window.
effectiveQueryNoThe query string as sent to MusicBrainz.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results to return (1–100)."New value: +"Positive integer page size (default 25); values above 100 are clamped to 100 with a notice. With MUSICBRAINZ_CLAMP_OVERSIZED_LIMITS=off, maximum 100 is enforced."
    • changedInput schema / properties / limit / maximum
      Previous value: -100New value: +9007199254740991
    • changedOutput schema / anyOf
      Previous value: -[
      -  {
      -    "not": {
      -      "required": [
      -        "error"
      -      ]
      -    },
      -    "required": [
      -      "entityType",
      -      "results",
      -      "effectiveQuery",
      -      "totalCount"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "error"
      -    ]
      -  }
      -]New value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "entityType",
      +      "offset",
      +      "results",
      +      "effectiveQuery",
      +      "totalCount"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • changedOutput schema / properties / notice / description
      Previous value: -"Guidance when zero results matched — how to broaden or correct the query."New value: +"Limit clamp and pagination guidance, including zero matches, exhausted pages, and empty-page discrepancies."
    • addedOutput schema / properties / offset
      Added value: +{
      +  "description": "The effective zero-based result offset used for this page.",
      +  "type": "number"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / results / items / properties / status
      Added value: +{
      +  "description": "Release status (e.g. Official or Bootleg). Omitted for other entity types or when absent.",
      +  "type": "string"
      +}
  3. Changed3 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Lucene query string. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported."New value: +"Lucene query string; must contain non-whitespace text. Plain text matches names/titles; field scoping (e.g. `artist:`, `country:`, `tag:`) is supported. Sent to MusicBrainz exactly as given."
    • changedOutput schema / properties / error / properties / data / properties / reason / description
      Previous value: -"Machine-readable failure mode."New value: +"Machine-readable failure mode. Declared by this tool: `blank_query`: The query contains only whitespace (it is blank after trimming). Other values are possible when a failure originates below the handler."
    • addedOutput schema / properties / error / properties / data / properties / reason / examples
      Added value: +[
      +  "blank_query"
      +]
  4. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "entityType",
      +      "results",
      +      "effectiveQuery",
      +      "totalCount"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Present when the call failed. Absent on success.",
      +  "properties": {
      +    "code": {
      +      "description": "JSON-RPC error code for this failure.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "data": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "reason": {
      +          "description": "Machine-readable failure mode.",
      +          "type": "string"
      +        },
      +        "recovery": {
      +          "additionalProperties": {},
      +          "description": "Actionable next step for the caller.",
      +          "properties": {
      +            "hint": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "hint"
      +          ],
      +          "type": "object"
      +        },
      +        "retryable": {
      +          "description": "Whether retrying may succeed.",
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "message": {
      +      "description": "Human-readable description of what went wrong.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "code",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "entityType",
      -  "results",
      -  "effectiveQuery",
      -  "totalCount"
      -]
  5. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, openWorld), so the description adds value by disclosing result ordering (score-descending), the 0–100 relevance scale with 100 = exact, and the returned fields including the status-vs-type distinction across entity types. It omits operational traits an agent might want — MusicBrainz rate limiting and whether the query is sent verbatim to a live remote service — leaving a small gap.

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

Conciseness4/5

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

Front-loaded with the core action and entity list, then return shape, then the workflow hint, then Lucene specifics — a sensible order. There is mild redundancy between 'Returns ranked matches' and 'Results are in MusicBrainz score-descending order', which restates the same property twice.

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

Completeness4/5

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

For a 4-param, 100%-covered schema with an output schema present, the description is close to complete: it defines the tool's role, query semantics, ordering, and downstream chaining. The remaining omissions are remote-service behavior (rate limits, error conditions) rather than selection-critical information.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description exceeds that by giving a concrete field-scoped Lucene example (`artist:radiohead AND country:GB`), clarifying that plain text matches names/titles, and warning that reference rows surface status while other subtypes surface type. It does not add anything about limit/offset beyond what the schema already documents.

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?

Names a specific verb ('Full-text search') plus the exact resource set (artist, release-group, release, recording, work, label) and the query mechanism (Lucene string). It also positions itself relative to siblings by describing itself as the name→MBID resolution entry point that feeds the musicbrainz_get_* tools, so an agent can place it in the workflow without opening other schemas.

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

Usage Guidelines4/5

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

Explicitly states the use case: 'Starting point when resolving a name to an MBID — chain the returned MBID into the matching musicbrainz_get_* tool.' That gives a clear when-to-use and a handoff. It does not say when to prefer musicbrainz_browse_entities or musicbrainz_lookup_identifier instead, so the alternative-selection guidance is incomplete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.