Harmonic mixing over MCP: the DJ set-builder Spotify never shipped

FreqBlog rebuilt Spotify's deprecated Audio Features, Recommendations, and Related Artists endpoints and added a DJ set-builder with harmonic mixing over MCP. The API exposes pairwise transition scoring, next-track ranking, and full setlist ordering around the Camelot wheel, accessible via REST or MCP for LLMs and agents.

When Spotify deprecated Audio Features, Recommendations, and Related Artists for new apps in November 2024, a wave of "drop-in replacement" APIs appeared. Most stop at parity: you send a track, you get BPM, key and energy back. Useful — but that's the same lookup Spotify already gave you. FreqBlog went a layer further. It rebuilt the dead endpoints, then shipped the thing Spotify never had: a set-builder . Pairwise transition scoring, next-track ranking, and full setlist ordering around the Camelot wheel. And the whole surface is exposed over an MCP server , so an LLM or agent can plan a DJ set by calling tools directly — no glue code between the model and the music theory. This is for people building music or AI tooling. I'll show the harmonic-mixing model concretely, then call it two ways: plain REST and MCP. Before the interesting part, the boring-but-necessary drop-ins: GET /recommendations and the MCP tool get recommendations — the replacement for the removed /v1/recommendations , re-ranked by genre affinity so a feature-close cross-genre track can't outrank same-genre picks. GET /related-artists — replaces the killed related-artists endpoint. GET /v1/audio-features/{id} returns a bare Spotify AudioFeaturesObject ; GET /v1/audio-features?ids= returns the {"audio features": ... } array envelope. Both mirror Spotify's own shapes, so porting existing code is a small diff.The native lookup is flatter and richer. GET /lookup resolves a track by name, ISRC, MusicBrainz ID or Spotify ID and returns one flat object — over 40 fields, no nesting: curl -s "https://api.freqblog.com/lookup?track=Strobe&artist=deadmau5&wait=10" \ -H "X-Api-Key: $FREQBLOG KEY" // shape values illustrative — every feature is top-level, no "audio features" wrapper { "track name": "Strobe", "artist name": "deadmau5", "bpm": 128.0, "key": "B", "camelot": "1A", "mode": "minor", "energy": 0.61, "danceability": 0.72, "valence": 0.35, "genre": "progressive house" } Two things worth knowing: bpm and key are always present and non-null, and ?wait=10 opts into a bounded synchronous mode — up to 25 seconds — that returns the analysed track inline as a 200 instead of the default 202 + Retry-After when a track isn't cached yet. Every musical key maps to a clock position on the Camelot wheel : a number 1 – 12 plus a letter A = minor, B = major . Two tracks mix without a key clash when they sit next to each other on the wheel: the same key, the relative major/minor same number, flipped letter , or the adjacent +1 / -1 neighbours. Jump +7 and you get the classic energy-boost mix. find compatible keys is pure theory — no catalog hit, zero quota : // find compatible keys camelot="8A", extended=true { "camelot": "8A", "compatible": { "camelot": "8A", "relation": "same" }, { "camelot": "8B", "relation": "relative" }, // minor <- major { "camelot": "7A", "relation": "adjacent down" }, // -1 { "camelot": "9A", "relation": "adjacent up" }, // +1 { "camelot": "3A", "relation": "energy boost" }, // +7 extended=true { "camelot": "1A", "relation": "energy drop" } // -7 extended=true } Knowing which keys could mix is table stakes. score transition rates how well one real track mixes into another, 0 – 100 , blending Camelot key compatibility, octave-aware BPM proximity half/double-time counts as a match , and energy smoothness — and it hands back a human reason: // score transition from track id="apple ad1829eeccb70f9a", // to track id="apple 7c1120fbe0" — costs 1 quota { "score": 91, "components": { "harmonic": 95, "tempo": 92, "energy": 86 }, "reason": "8A- 9A +1 adjacent, 126- 128 BPM +2.0 , energy +0.04" } There's no raw key/BPM endpoint anywhere that gives you that — the pairwise judgement is the product. suggest next track takes the track that's playing and returns the top-N catalog tracks to play next, each with the same score, components and reason e.g. "11B- 11B same key, 118- 117 BPM -0.29 , energy +0.12" . It's genre-aware by default, so an off-genre track that only coincidentally shares your key/BPM sinks to the bottom. build setlist orders an entire crate 2–100 tracks into a beat-matched set that follows an energy arc — peak time , warmup , cooldown , or flat — keeping every consecutive transition harmonically and tempo-smooth. It returns an overall flow score , the tracks in play order, and the per-step transitions. Here's where it stops being an API and starts being a capability you hand to a model. Point any MCP client at: https://mcp.freqblog.com/mcp That exposes twelve tools — search catalog , get audio features , get audio features batch , find tracks by bpm , find tracks by key , find compatible keys , get recommendations , get related artists , score transition , suggest next track , build setlist , tag track . The agent orchestrates them itself. A single prompt like "build me a 90-minute peak-time set from these ten tracks" becomes: search catalog on each fuzzy name → concrete itunes track id s build setlist track ids= ... , arc="peak time" → ordered set + flow score itunes track id s to GET /export/rekordbox also traktor , m3u , cuesheet , csv and drop the crate straight into your DJ softwareNo orchestration code on your side — the tool descriptions carry enough for the model to chain them. The set-builder tools cost a little more quota than a plain lookup score transition 1, get recommendations 2, suggest next track 3, build setlist 5 , because each one is doing real combinatorial work. Auth is an X-Api-Key header a ?key= query fallback exists for browser and email links . Everything above is also available as plain REST — GET /transition , GET /next-track , POST /setlist , GET /similar?track id=... — if you'd rather not run an MCP client. It's on RapidAPI too. Pricing starts at £0.17/1k , and the free tier is 1,000 requests/month, which is plenty to prototype a set planner. itunes track id s, so a track has to resolve first search catalog / /lookup . Coverage is deep but not universal — niche or regional catalogs have holes. /analyze and /identify — not the audio itself.Grab a free key and the OpenAPI docs at api.freqblog.com/docs , or read more about the API on