FreqBlog Music Metadata

Search Music Catalog

search_catalog

Read-only

Full-text search the catalog by any mix of track / artist / album tokens. Use this to resolve a fuzzy, partial, or misspelled name into concrete tracks BEFORE calling get_audio_features.

Each hit carries `chart_peak`: the best chart position we hold, 1-100 with 100 = a
number-one. `null` means no placement we hold — treat that as UNKNOWN, not unpopular,
and note it is NOT an audience-size figure. Coverage is Billboard year-end only so far.

Returns lightweight stubs (itunes_track_id, track_name, artist_name, album, etc.) ranked
by relevance — NOT audio features. Take the best match's track_name + artist_name and
pass them to get_audio_features, or reuse its itunes_track_id as a `track_id` seed for
discovery tools.

⚠ Each hit carries a `seedable` boolean. Only a hit with `seedable: true` can be used as
a seed for get_recommendations / suggest_next_track / build_setlist / score_transition —
those work off the similarity index, which holds only tracks we have analysed, and about
a quarter of the catalogue is not analysed yet. **Prefer the highest-ranked hit with
`seedable: true`.** Seeding with a `seedable: false` id returns a 404; if that track is
the one you want, call get_audio_features on it first to queue analysis, then retry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`q`	Yes	Search query — any mix of artist / track / album tokens.
`limit`	No	Max results (default 10).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedJun 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds crucial behavioral details: returns lightweight stubs ranked by relevance, explains chart_peak semantics (100 = number-one, null = UNKNOWN not unpopular, Billboard year-end only), and explains the seedable boolean with its implications (404, queue analysis). This is rich context beyond 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 long but every section serves a purpose: purpose, usage, result interpretation, and seeding rules. It is front-loaded with the main purpose and then layers detail logically. No filler; each sentence earns its place.

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?

Given the complexity (chart_peak interpretation, seedable flag, 404 behavior, routing to other tools), the description covers all necessary behavioral aspects for correct invocation. The output schema exists but the description adds the semantic nuances that schema cannot convey. Nothing an agent needs is missing.

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 both q and limit having descriptions. The description doesn't add new input semantics beyond schema, but it does clarify usage of q in context (any mix of tokens). Since schema already covers parameters, 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 opens with a specific verb and resource ('Full-text search the catalog by any mix of track / artist / album tokens') and immediately differentiates from siblings by stating it resolves fuzzy names before calling get_audio_features, and by noting it returns stubs not audio features. This gives an agent a clear, distinct purpose.

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?

Explicitly states when to use it ('BEFORE calling get_audio_features') and provides detailed follow-up instructions: take best match and pass to get_audio_features or reuse itunes_track_id as seed, plus guidance on seedable flag and 404 handling. This is far beyond typical guidance and routes the agent to the correct next steps.

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

All FreqBlog Music Metadata 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.

Resources

Need Help?