FreqBlog Music Metadata

Get Audio Features

get_audio_features

Read-only

Get audio features for ONE track — BPM, musical key (name + Camelot + Open Key), energy, danceability, valence, acousticness, instrumentalness, liveness, speechiness, loudness, mood, mood_vector, genre, time signature, duration and more.

This is the drop-in replacement for Spotify's deprecated /audio-features endpoint.
Provide AT LEAST ONE identifier — if you know several, send them all rather than
choosing; they resolve by precedence (`track` > `isrc` > `mbid` > `spotify_id`) and
the rest are ignored:
  - `track` (optionally with `artist`) — e.g. track="Blinding Lights", artist="The Weeknd".
  - `isrc` — e.g. "USUM71900001".
  - `mbid` — a MusicBrainz recording UUID.
  - `spotify_id` — a Spotify track ID, URI, or URL (resolved from our ID map or by
    matching the track's title; ambiguous titles miss rather than guess — prefer
    `track`/`isrc` for full coverage).

Returns a JSON object of features. Some feature fields may be null for tracks resolved
via the fallback catalogs (only audio-derived values are present for fully analysed
tracks). If a track name is not yet in the catalog, the API holds the request during the
on-demand ingest and usually returns the fully analysed track inline in this same call;
only if the ingest runs long does it fall back to a queued response you can re-poll
shortly (~15s). If the track turns out not to be on any streaming source we can analyse,
you get a definitive not-found instead — that verdict is terminal for ~7 days, so don't
retry it. If you only have a fuzzy or partial name, call search_catalog first to
find the exact track.

Input Schema

TableJSON Schema

Name	Required	Description
`isrc`	No	ISRC, e.g. 'USUM71900001'.
`mbid`	No	MusicBrainz recording ID (UUID). The precise key when there is no ISRC, e.g. pre-1986 recordings.
`track`	No	Track title. Use with `artist` when known. Supply AT LEAST ONE of track/isrc/mbid/spotify_id. Sending several is fine — they resolve by precedence (track > isrc > mbid > spotify_id) and the rest are ignored.
`artist`	No	Artist name. Only used with `track`; required when the title is <=2 characters.
`spotify_id`	No	Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolved from our Spotify-ID map or, on a miss, by matching the track's title — a title several artists share is ambiguous and misses rather than guessing; prefer track (+artist) or isrc.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses substantial behavioral traits: identifier precedence, null fields for fallback catalogs, on-demand ingest that may hold the request, a queued response fallback after ~15s, and a terminal 7-day not-found verdict. This gives the agent accurate expectations about latency and retry behavior.

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 longer than average, but every sentence earns its place: purpose is front-loaded, identifier guidance is bulleted, and edge-case behaviors are clearly separated. The detail is justified by the tool's complex resolution and ingest behavior.

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 output schema is provided and annotations cover read-only/open-world behavior, the description completes the picture: return shape, null handling, fallback catalogs, ingest latency, poll timing, and definitive not-found semantics. Nothing needed to invoke the tool correctly is missing.

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 value beyond the schema: it explains the full precedence order (track > isrc > mbid > spotify_id), advises sending several identifiers instead of choosing, and gives realistic examples. It largely reinforces rather than replaces the schema, so slightly above baseline.

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: 'Get audio features for ONE track', followed by a concrete list of returned features. It clearly distinguishes this single-track tool from the batch sibling and from search_catalog.

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 gives explicit guidance on identifier selection, precedence, and tells users to 'call search_catalog first' when they only have a fuzzy name. However, it never explicitly routes multi-track requests to the get_audio_features_batch sibling; it only implies that through 'ONE track'.

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

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 clearly distinct purpose: search, feature retrieval, set building, transition scoring, etc. There is no overlap or ambiguity.

Naming Consistency5/5

All tools use consistent snake_case verb_noun pattern (e.g., find_tracks_by_key, get_audio_features, build_setlist). No style mixing.

Tool Count5/5

12 tools is well within the ideal range, covering search, features, discovery, and set building without bloat or deficiency.

Completeness4/5

Core metadata retrieval, search, harmonic mixing, and DJ set tools are all present. Minor gaps like user library management are outside the scope.

Resources

Need Help?