get_recommendations
Recommended tracks for one or more seed tracks — the drop-in for Spotify's removed GET /v1/recommendations. Blends up to 5 catalog seed tracks into a single point in audio-feature space and returns the nearest catalogue tracks, RE-RANKED by genre affinity (so a feature-close cross-genre track doe...
This record as markdown: /tools/com-freqblog-music-metadata/get-recommendations.md
What get_recommendations does on FreqBlog Music Metadata
AI agents call get_recommendations 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 |
|---|---|---|---|
max | object | — | HARD upper bounds, e.g. {'tempo': 130}. Same attributes as `min`. Combine the two for a range. |
min | object | — | HARD lower bounds, e.g. {'tempo': 100, 'energy': 0.5}. Tracks below the bound — and tracks we hold no analysed value for — are dropped. Attributes: acousticness |
limit | integer | — | Number of recommendations to return (default 20). |
track | object | — | Seed by track NAME instead of an id — resolved to the best catalog match (echoed back as seed_query). Pair with artist to disambiguate. Ignored when seed_tracks |
artist | object | — | Artist name narrowing the track seed (case-insensitive). |
target | object | — | PREFERRED values, e.g. {'energy': 0.8}. Tracks nearer the value rank higher; unlike min/max nothing is removed. Same attributes as `min`. |
cross_genre | string | — | Genre handling (mirrors suggest_next_track): 'auto' (default) re-ranks by genre affinity so a feature-close cross-genre track can't outrank same-genre picks; 's |
seed_tracks | object | — | 1-5 catalog itunes_track_ids to base recommendations on, e.g. ['apple_ad1829eeccb70f9a'] (blended into a feature-space centroid). Omit and use track(+artist) to |
exclude_seed_artists | boolean | — | Drop tracks by any of the seed artists (default false). |
Parameters from the server's own tool schema.
Why get_recommendations is rated Low
Even though get_recommendations 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_recommendations 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_recommendations, this is the rule to start with:
get_recommendations 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_recommendations call is checked against it from then on.
Questions about get_recommendations
Recommended tracks for one or more seed tracks — the drop-in for Spotify's removed GET /v1/recommendations. Blends up to 5 catalog seed tracks into a single point in audio-feature space and returns the nearest catalogue tracks, RE-RANKED by genre affinity (so a feature-close cross-genre track doesn't outrank same-genre picks). Returns seeds (each {id, found}), count, and tracks (each {track, score, genre_relation}; each track carries its genre). genre_relation is "same", "compatible" (different but mixable family), "cross" (unrelated), or "unknown" (either side has no mapped genre), measured against the PRIMARY seed — the first of your seed_tracks we could actually use, so reordering seed_tracks changes it and a skipped seed never becomes the reference. With a SINGLE seed the field is the ranking's own verdict, so it explains the order (same as suggest_next_track). With SEVERAL seeds the ranking considers ALL of them while the label stays relative to your primary seed, so a "cross" label on a multi-seed call does NOT mean the track was pushed down — it may share a family with another of your seeds. score is the raw audio-feature cosine similarity in [0,1]; genre affinity influences the ORDER, not the score, so the list is NOT strictly score-descending. Use cross_genre=strict to return same-genre-family tracks ONLY (off-genre dropped server-side), or allow to disable the genre ranking. seed_tracks are catalog itunes_track_ids from search_catalog or the itunes_track_id field of a get_audio_features result. NO id? Pass track (+ optional artist) instead and we resolve the name to the best catalog match and seed on it — the resolved track is echoed back as seed_query; seed_tracks wins if both are given. TUNING: min/max are HARD filters and target is a preference (nearer ranks higher, nothing removed), over acousticness, danceability, duration_ms, energy, instrumentalness, liveness, loudness, popularity, speechiness, tempo and valence. e.g. min={"tempo": 100}, max={"tempo": 130}, target={"energy": 0.8} for energetic 100-130 BPM tracks. When you tune, the response adds a filters block saying what applied, how many tracks each bound removed (dropped_by) and whether the bounds ran out of catalogue before limit (limit_reached) — if the list comes back short, read that BEFORE assuming the catalogue is thin. Costs 2 quota units. It is categorised as a Read tool in the FreqBlog Music Metadata MCP Server, which means it retrieves data without modifying state.
get_recommendations accepts 9 parameters: max, min, limit, track, artist, target, cross_genre, seed_tracks, exclude_seed_artists. 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_recommendations: 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_recommendations 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_recommendations 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_recommendations. 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_recommendations 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