Skip to main content
Glama

FreqBlog Music Metadata

Discover Tracks by Criteria

discover_tracks
Read-only

Find catalog tracks by criteria, with no seed track: tempo, key, genre, release year, chart placement and audio-feature ranges in one call — e.g. house at 122-126 BPM in 8A or its neighbours with energy above 0.7: min={"tempo": 122, "energy": 0.7}, max={"tempo": 126}, key="8A", harmonic=true, genre="house".

At least one narrowing filter is required (a tempo/feature bound, key, mode, genre, year
or chart). Returns `results` (one per recording, each with its bpm, camelot, energy,
danceability, valence, acousticness and loudness_db plus catalog metadata),
`total_matches` (exact up to 1,000; `total_matches_capped` above that), `next_offset`
for the next page, and `filters` — what was applied and how many tracks each filter
removed (`dropped_by`); if the list is short, loosen the largest one. energy, danceability
and valence are on FreqBlog's own scales, so derive thresholds from values you have seen
rather than from another service's. Results reach a depth of 500 per query; narrow the
filters to go further. Pass a result's itunes_track_id to get_audio_features for every
field, or to suggest_next_track / build_setlist. Costs 1 quota unit.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "discover_tracks"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoComma list of keys: Camelot ('8A'), Open Key ('1m') or names ('A minor').
maxNoHARD upper bounds, e.g. {'tempo': 126}. Same attributes as `min`; combine the two for a range.
minNoHARD lower bounds, e.g. {'tempo': 122, 'energy': 0.7}. Tracks below the bound, and tracks with no analysed value, are excluded. Attributes: acousticness, danceability, duration_ms, energy, loudness, tempo, valence.
modeNo'major' or 'minor' only.
sortNo'chart' (default: charted first, then newest), 'newest', 'oldest', 'tempo', '-tempo', 'energy', '-energy', or 'target' (default when `target` is given).chart
genreNoComma list of catalog genre names, e.g. 'house' or 'hip-hop,r&b'. Unknown names in a list are skipped and listed in filters.ignored with close matches; only a list where every name is unknown is rejected.
limitNoTracks per page (default 20).
offsetNoSkip this many tracks for the next page; offset + limit may not exceed 500.
targetNoPREFERRED values, e.g. {'energy': 0.8}: nearest first, nothing removed. Same attributes as `min`.
chartedNotrue = only tracks with a known chart placement (about 4% of tracks have one).
explicitNotrue = explicit tracks only, false = non-explicit only; omit for either.
harmonicNoWiden each key to its harmonically compatible keys (same, relative, one step either way on the Camelot wheel).
max_yearNoLatest release year.
min_yearNoEarliest release year.
tempo_matchNo'exact' (default) or 'half_double' — also match double/half the min/max tempo range (an 87 BPM track for a 174 BPM set).exact
min_chart_peakNoBest chart position required, as chart_peak (1-100, 100 = a number one).
include_subgenresNoAlso match every subgenre of a top-level genre.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / genre / description
      Previous value: -"Comma list of catalog genre names, e.g. 'house' or 'hip-hop,r&b'. An unknown name is rejected with close matches."New value: +"Comma list of catalog genre names, e.g. 'house' or 'hip-hop,r&b'. Unknown names in a list are skipped and listed in filters.ignored with close matches; only a list where every name is unknown is rejected."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the readOnly/openWorld annotations, it discloses quota cost (1 unit), a 500-result depth ceiling per query, exact-vs-capped match counts (1,000 threshold), one row per recording, and the filters.dropped_by diagnostic that explains why results were excluded. The warning that energy/danceability/valence use FreqBlog's own scales and thresholds must be derived from observed values is a genuinely important behavioral caveat no annotation could convey.

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 purpose, then a concrete example, then return shape, then constraints — a sensible ordering with no filler sentences. It is on the long side, but every clause carries operational information (depth cap, quota, required filter, dropped_by), so nothing is obviously expendable.

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?

For a 17-parameter discovery tool this covers everything an agent needs: the required-filter rule, result depth ceiling, pagination via next_offset, quota cost, and how to interpret the filter diagnostics. Even though an output schema exists, the description's summary of results/total_matches/filters is consistent with it rather than redundant padding.

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, but the description adds real meaning: a worked example showing min/max combined into a range, harmonic widening of keys, and the semantic split between min/max (hard bounds that exclude) versus target (preferred values that never remove). The scale caveat also changes how an agent should choose numeric thresholds.

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?

Opens with a specific verb+resource ("Find catalog tracks by criteria") and immediately distinguishes itself from seed-based siblings with "with no seed track", then enumerates the exact dimensions it can filter on (tempo, key, genre, year, chart, audio features). An agent can tell this apart from find_similar_tracks or find_tracks_by_bpm without opening any schema.

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?

States a hard usage precondition ("At least one narrowing filter is required") and gives operational guidance on what to do when results are thin ("loosen the largest one" from dropped_by). It also points to downstream tools (get_audio_features, suggest_next_track, build_setlist) for the follow-up step. What it lacks is an explicit routing statement against the single-criterion siblings like find_tracks_by_bpm or find_tracks_by_key.

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.

Resources