get_audio_features
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 /a...
This record as markdown: /tools/com-freqblog-music-metadata/get-audio-features.md
What get_audio_features does on FreqBlog Music Metadata
AI agents call get_audio_features to retrieve information from FreqBlog Music Metadata without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
isrc | object | — | ISRC, e.g. 'USUM71900001'. |
mbid | object | — | MusicBrainz recording ID (UUID). The precise key when there is no ISRC, e.g. pre-1986 recordings. |
track | object | — | 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 |
artist | object | — | Artist name. Only used with `track`; required when the title is <=2 characters. |
spotify_id | object | — | 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 (+ar |
Parameters from the server's own tool schema.
Why get_audio_features is rated Low
Even though get_audio_features only reads data, uncontrolled read access leaks sensitive information and racks up API costs: an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.
Attacks that exploit this kind of access
The rule that runs get_audio_features safely
PolicyLayer is an MCP gateway: it sits between your AI agents and FreqBlog Music Metadata, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For get_audio_features, this is the rule to start with:
get_audio_features is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect FreqBlog Music Metadata, apply this rule, and every get_audio_features call is checked against it from then on.
Questions about get_audio_features
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 (resolves only the <1% of the catalog already mapped to a Spotify ID; 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. It is categorised as a Read tool in the FreqBlog Music Metadata MCP Server, which means it retrieves data without modifying state.
get_audio_features accepts 5 parameters: isrc, mbid, track, artist, spotify_id. The full parameter table on this page comes from the server's own tool schema.
Register the FreqBlog Music Metadata MCP server in PolicyLayer and add a rule for get_audio_features: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches FreqBlog Music Metadata. Nothing to install.
get_audio_features is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_audio_features rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for get_audio_features. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_audio_features is provided by the FreqBlog Music Metadata MCP server (https://mcp.freqblog.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on FreqBlog Music Metadata, and thousands of servers like it.
This server
Across the catalogue