Skip to main content
Glama

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, 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 per request by reading
    the track's title from Spotify's public embed page and matching it against our
    catalogue — no Spotify IDs are stored; 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).

VALUES are FreqBlog's own analysis, NOT on Spotify's scale: energy and valence are on
our own raw scale (derive thresholds from our values, don't copy Spotify-tuned ones);
danceability and acousticness are on AcousticBrainz's scale -- its classifier where
available, else a model that listens to the preview, built on PANNs embeddings
(Kong et al. 2020, CC BY 4.0); instrumentalness, speechiness and liveness are currently
null for catalogue 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
NameRequiredDescriptionDefault
isrcNoISRC, e.g. 'USUM71900001'.
mbidNoMusicBrainz recording ID (UUID). The precise key when there is no ISRC, e.g. pre-1986 recordings.
trackNoTrack 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.
artistNoArtist name. Only used with `track`; required when the title is <=2 characters.
spotify_idNoSpotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolved per request by reading the track's title from Spotify's public embed page and matching it against our catalogue (no Spotify IDs are stored) — a title several artists share is ambiguous and misses rather than guessing; prefer track (+artist) or isrc.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / spotify_id / description
      Previous value: -"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."New value: +"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolved per request by reading the track's title from Spotify's public embed page and matching it against our catalogue (no Spotify IDs are stored) — a title several artists share is ambiguous and misses rather than guessing; prefer track (+artist) or isrc."
  2. Changed1 schema field changed
    • changedInput schema / properties / spotify_id / description
      Previous value: -"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolves ONLY tracks already mapped to a Spotify ID (<1% of the catalog) — prefer track (+artist) or isrc."New value: +"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."
  3. Changed1 schema field changed
    • changedInput schema / properties / track / description
      Previous value: -"Track title. Use with `artist` when known. Required field is ONE of track/isrc/mbid/spotify_id."New value: +"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."
  4. Changed1 schema field changed
    • changedInput schema / properties / spotify_id / description
      Previous value: -"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolves ONLY tracks already mapped to a Spotify ID (~2.4% of the catalog) — prefer track (+artist) or isrc."New value: +"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolves ONLY tracks already mapped to a Spotify ID (<1% of the catalog) — prefer track (+artist) or isrc."
  5. Changed1 schema field changed
    • changedInput schema / properties / spotify_id / description
      Previous value: -"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL."New value: +"Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. Resolves ONLY tracks already mapped to a Spotify ID (~2.4% of the catalog) — prefer track (+artist) or isrc."
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes far beyond by disclosing that values are on FreqBlog's own scale (not Spotify's), that certain fields are null for catalogue tracks, that Spotify IDs are resolved per request via the embed page without storage, and that a not-found verdict is terminal for ~7 days with an ingest/queue fallback (~15s re-poll). This is unusually rich behavioral context.

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 purpose and field list, then organized into identifier bullets and caveats. Every sentence carries information, but the total length is substantial and the parenthetical detail (citations, resolution mechanics) makes it denser than strictly needed.

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?

An output schema exists, so return values need not be spelled out, yet the description still notes that feature fields may be null and explains scale caveats. Combined with identifier rules and ingest/retry behavior, nothing an agent needs to call this 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% (baseline 3), but the description adds real value beyond the schema: the precedence order among the four identifiers, the rule that the rest are ignored, the semantics of the spotify_id resolution and its ambiguity behavior, and format examples. Only slightly short of a 5 since most field-level detail still lives in the schema.

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?

States a specific verb and resource ('Get audio features for ONE track'), enumerates the returned fields (BPM, key, energy, danceability, etc.), and implicitly distinguishes itself from the sibling get_audio_features_batch by emphasizing ONE track. An agent can tell exactly what this returns without opening the schema.

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 says 'Provide AT LEAST ONE identifier', gives the resolution precedence (track > isrc > mbid > spotify_id), advises sending all known identifiers, and routes fuzzy/partial names to search_catalog first. Clear when-to-use and which alternative to pick.

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