apibase

Search Music Releases

music.releases.search

Read-onlyIdempotent

Search for albums, singles, and EPs across 50M+ recordings — title, artist, date (MusicBrainz)

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max results to return (1-100, default 25)
`query`	Yes	Search query for release/album title (e.g. "OK Computer", "Kind of Blue"). Supports Lucene syntax: artist:"Radiohead" AND release:"OK Computer"
`offset`	No	Pagination offset for results

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No	Present only when the call failed. Includes error code, message, request_id, and any provider-specific extras.
`result`	No	Tool response payload. Shape varies per tool — consult the tool description and inputSchema. May be an object, array, string, or number depending on the upstream provider response.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare read-only, non-destructive, idempotent behavior. The description adds context (MusicBrainz, 50M+ recordings) but not additional behavioral traits like rate limits or pagination details. It 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.

Conciseness5/5

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

Single sentence with a parenthetical note, front-loaded with key action and scope. Every word is meaningful, no redundancy.

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?

Given annotations and output schema, the description adequately covers purpose, scope, and data source. It could mention pagination or sort order but is sufficient for an informed agent.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions and examples. The description adds minimal extra meaning beyond schema, merely reinforcing searchable fields. Baseline 3 is appropriate.

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 clearly states the tool searches for albums, singles, and EPs, specific resource types, and distinguishes from sibling tools like music.artists.search and music.recordings.search by focusing on releases. It also mentions the data source (MusicBrainz) and available search criteria (title, artist, date).

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?

The description implies the tool is for release-type searches but does not explicitly contrast with siblings or provide when-not-to-use guidance. It clearly defines scope but lacks direct alternative recommendations.

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

All apibase tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.