FreqBlog Music Metadata
REMOTE · MCP.FREQBLOG.COM · SCANNED SEP 21
Audio features + harmonic set-building for tracks by name/ISRC. Spotify audio-features replacement.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- The endpoint enforces authorisation, but returns a challenge with no valid RFC 9728 metadata, so a client cannot discover where to get a token. See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport blocked by authentication: the endpoint requires auth we don't have to verify streamable-http. See how to fix → View diagnostics → Unverified
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4958 tokens (~413/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Unverified: 1 category
A category scored 0 because we couldn't verify past authentication. We only credit what we can confirm, so an authenticated endpoint we can't read counts against the score. Claim this server and supply a read-only token to verify it and lift the score.
How do I install the FreqBlog Music Metadata MCP server?
FreqBlog Music Metadata is a hosted endpoint at https://mcp.freqblog.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.freqblog.com
claude mcp add --transport http com-freqblog-music-metadata 'https://mcp.freqblog.com/mcp'
{
"mcpServers": {
"com-freqblog-music-metadata": {
"url": "https://mcp.freqblog.com/mcp"
}
}
} {
"servers": {
"com-freqblog-music-metadata": {
"type": "http",
"url": "https://mcp.freqblog.com/mcp"
}
}
} [mcp_servers.com-freqblog-music-metadata] url = "https://mcp.freqblog.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-freqblog-music-metadata": {
"type": "remote",
"url": "https://mcp.freqblog.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-freqblog-music-metadata --url 'https://mcp.freqblog.com/mcp' --transport streamable-http
mcp_servers:
com-freqblog-music-metadata:
url: "https://mcp.freqblog.com/mcp" {
"McpServers": {
"com-freqblog-music-metadata": {
"Transport": "http",
"Url": "https://mcp.freqblog.com/mcp"
}
}
} assistant mcp add com-freqblog-music-metadata -t streamable-http -u 'https://mcp.freqblog.com/mcp'
{
"mcpServers": {
"com-freqblog-music-metadata": {
"type": "http",
"url": "https://mcp.freqblog.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 16 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “find_tracks_by_bpm” rewrote its description, which is the text the model reads security
- Tool “find_tracks_by_key” rewrote its description, which is the text the model reads security
- Tool “get_audio_features_batch” rewrote its description, which is the text the model reads security
- Tool “get_recommendations” rewrote its description, which is the text the model reads security
- Tool “search_catalog” rewrote its description, which is the text the model reads security
- “get_recommendations” reworded the description of “min” cosmetic
- 31 Aug 26 +1
- Authorization: unverified → fail ▼ security
- Transport: pass → unverified ▼ security
- Stability: 0.97 → pass security
- 30 Aug 26 −1
- Stability: pass → 0.97 functional
- 27 Aug 26 +1
- Tool “get_audio_features” rewrote its description, which is the text the model reads security
- “get_audio_features” reworded the description of “spotify_id” cosmetic
- “tag_track” reworded the description of “spotify_id” cosmetic
- 26 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 +1
- Stability: 0.97 → pass security
- 18 Aug 26 0
- Tool “get_recommendations” rewrote its description, which is the text the model reads security
- “get_recommendations” added an optional parameter “max” cosmetic
- “get_recommendations” added an optional parameter “min” cosmetic
- “get_recommendations” added an optional parameter “target” cosmetic
- 13 Aug 26 0
- Tool “get_audio_features” rewrote its description, which is the text the model reads security
- Tool “tag_track” rewrote its description, which is the text the model reads security
- “get_audio_features” reworded the description of “track” cosmetic
- “tag_track” reworded the description of “track” cosmetic
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Probed https://mcp.freqblog.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=freqblog.com | CN=YE2,O=Let's Encrypt,C=US | 19 Sept 2026 | 18 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 52f3b1746838d5c16728a883f3361bf210a |
| SANs: *.freqblog.com, freqblog.com | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.freqblog.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| freqblog.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Challenged, unverified
The endpoint asked for a token, but we could not retrieve and validate the RFC 9728 metadata that tells a client how to obtain one.
| Result | Challenged, unverified |
|---|---|
| Enforced | On connection |
| HTTP status | 403 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| x-content-type-options | nosniff |
| referrer-policy | strict-origin-when-cross-origin |
Protected resource metadata
| Retrieved | No |
|---|---|
| Problem | no_resource_metadata |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.freqblog.com/mcp | Auth required | 403 | |
| http (plaintext) | http://mcp.freqblog.com/mcp | HTTPS enforced | 301 | https://mcp.freqblog.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
build_setlist Build Setlist ~248
Order a crate of 2-100 catalog tracks into a beat-matched DJ set that follows an energy arc, keeping each consecutive transition harmonically and tempo-smooth. `arc` is one of peak_time (default — builds to a peak then eases), warmup, cooldown, or flat. Returns the `arc`, `count`, an overall `flow_score` (0-100), the `tracks` in play order, the per-step `transitions` ({from_index, to_index, score, reason}), and `omitted` (ids not found in the catalog). Feed tracks[].itunes_track_id into a Rekordbox/Serato export to drop the set straight into your DJ software. track_ids are catalog itunes_track_ids. Costs 5 quota units.
| Name | Type | Req | Description |
|---|---|---|---|
| arc | string | – | Energy arc: 'peak_time' (default), 'warmup', 'cooldown', or 'flat'. |
| start_track_id | – | – | Optional fixed opener — must be one of track_ids. |
| track_ids | array | yes | The crate to order — 2 to 100 catalog itunes_track_ids. |
Structured output declared, but exposes no named fields.
No examples provided.
find_compatible_keys Find Harmonically Compatible Keys ~160
Given a Camelot key (e.g. "8A", "12B"), return the harmonically compatible keys for DJ mixing — the same key, the relative major/minor, and the adjacent +/-1 keys on the Camelot wheel. With `extended=true` also returns the +7/-7 energy-boost / energy-drop keys. Pure music theory — no catalog lookup and no quota cost. Pair with find_tracks_by_key to then pull actual tracks in each compatible key.
| Name | Type | Req | Description |
|---|---|---|---|
| camelot | string | yes | Camelot key, e.g. '8A' or '12B'. |
| extended | boolean | – | Also return the +7/-7 energy-boost / energy-drop keys. |
Structured output declared, but exposes no named fields.
No examples provided.
find_tracks_by_bpm Find Tracks by BPM ~136
Find catalog tracks near a target tempo. Returns tracks whose BPM is within +/-`tolerance` of `bpm`, ordered by closeness then by an internal catalogue ordering key (not an audience metric) — useful for DJ set planning, workout playlists, or tempo-matching. Each returned track carries full audio features. To also constrain by musical key, combine with find_tracks_by_key.
| Name | Type | Req | Description |
|---|---|---|---|
| bpm | number | yes | Target tempo in BPM. |
| limit | integer | – | Max tracks (default 10). |
| tolerance | number | – | Plus/minus BPM window (default 2). |
Structured output declared, but exposes no named fields.
No examples provided.
find_tracks_by_key Find Tracks by Musical Key ~149
Find catalog tracks in a given musical key — for harmonic mixing and key-locked playlists. `key` accepts Camelot ("8A"), Open Key ("1m"), or a key name ("A-Minor", "F#-Major"). Returns tracks ordered by an internal catalogue ordering key (not an audience metric), each with full audio features. To discover which keys mix well with a given key first, use find_compatible_keys.
| Name | Type | Req | Description |
|---|---|---|---|
| key | string | yes | Camelot ('8A'), Open Key ('1m'), or key name ('A-Minor', 'F#-Major'). |
| limit | integer | – | Max tracks (default 10). |
Structured output declared, but exposes no named fields.
No examples provided.
get_audio_features Get Audio Features ~609
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.
| Name | Type | Req | Description |
|---|---|---|---|
| artist | – | – | Artist name. Only used with `track`; required when the title is <=2 characters. |
| isrc | – | – | ISRC, e.g. 'USUM71900001'. |
| mbid | – | – | MusicBrainz recording ID (UUID). The precise key when there is no ISRC, e.g. pre-1986 recordings. |
| spotify_id | – | – | 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 miss… |
| track | – | – | 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… |
Structured output declared, but exposes no named fields.
No examples provided.
get_audio_features_batch Get Audio Features (Batch) ~370
Get audio features for MANY tracks in one call (up to 50 processed) — ideal for analysing a whole playlist at once. Identify each item by name (`track`/`artist`), by `isrc` (matched exactly first — best for CJK / K-pop / niche tracks whose fuzzy name-match misses), or both (ISRC first, name as the fallback). One bad entry never fails the batch. Items beyond the 50-per-call cap come back with `found: false` and `backfill_status: "over_limit"`; an item missing BOTH `track` and `isrc` comes back `"invalid_no_query"`. Neither is processed or charged — the response's `skipped` field counts them, so split a long list into calls of <=50 and resubmit any skipped rows. Returns counts (`found` / `not_found` / `skipped`) plus a per-track `results` array, where each entry's `result` is the same feature object as get_audio_features (or null when not found), and `isrc` is echoed back. An item is billed only when it returns features or queues an on-demand ingest; an ISRC/name with no match anywhere is free. A track you queue and then collect costs ONE unit, not two — the call that collects it is free. For a single track, use get_audio_features.
| Name | Type | Req | Description |
|---|---|---|---|
| tracks | array | yes | List of {track?, artist?, isrc?} objects. Up to 50 are processed per call; any extra (up to 200 accepted) come back skipped. Each item should carry `track` or `isrc`. |
Structured output declared, but exposes no named fields.
No examples provided.
get_recommendations Get Recommendations ~1,027
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, in…
| Name | Type | Req | Description |
|---|---|---|---|
| artist | – | – | Artist name narrowing the track seed (case-insensitive). |
| 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; 'strict' = same genre-family only (off-ge… |
| exclude_seed_artists | boolean | – | Drop tracks by any of the seed artists (default false). |
| limit | integer | – | Number of recommendations to return (default 20). |
| max | – | – | HARD upper bounds, e.g. {'tempo': 130}. Same attributes as `min`. Combine the two for a range. |
| min | – | – | 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, danceability, duration_ms, energy, in… |
| seed_tracks | – | – | 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 seed by name instead. |
| target | – | – | PREFERRED values, e.g. {'energy': 0.8}. Tracks nearer the value rank higher; unlike min/max nothing is removed. Same attributes as `min`. |
| track | – | – | 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 is given. |
Structured output declared, but exposes no named fields.
No examples provided.
get_related_artists Get Related Artists ~193
Artists related to a seed artist — the drop-in for Spotify's removed GET /v1/artists/{id}/related-artists. No artist graph exists, so we derive one: build the seed artist's track-vector centroid, take its nearest catalogue tracks, aggregate by artist (each scored on its top-3 track similarities so a prolific artist can't dominate) plus a same-genre lift and a cross-genre penalty. Returns `artist`, `count`, and `related` (each {artist_name, score, match_count, sample_track_id}). Pass a sample_track_id straight to get_audio_features or suggest_next_track. Costs 2 quota units.
| Name | Type | Req | Description |
|---|---|---|---|
| artist | string | yes | Seed artist name (as it appears in the catalog; case-insensitive). |
| limit | integer | – | Number of related artists to return (default 20). |
Structured output declared, but exposes no named fields.
No examples provided.
score_transition Score Transition ~267
Score how well one catalog track mixes into another (0-100) — the pairwise DJ transition score no raw key/BPM API gives you. Combines Camelot-wheel key compatibility, octave-aware BPM proximity (half/double-time counts as a match), and energy smoothness. Returns the overall `score`, per-component scores (`harmonic`/`tempo`/`energy`), a `detail` block (key_relation, both Camelot keys, both BPMs, bpm_delta, bpm_octave_matched, both energies, energy_delta), and a one-line human `reason` (e.g. "8A->9A adjacent (+1), 126->128 BPM (+2), energy +0.04 — clean uplifting mix"). Both ids are catalog itunes_track_ids — get them from search_catalog or the itunes_track_id field of a get_audio_features result. Costs 1 quota unit.
| Name | Type | Req | Description |
|---|---|---|---|
| from_track_id | string | yes | The track you're mixing FROM — a catalog itunes_track_id, e.g. 'apple_ad1829eeccb70f9a'. |
| to_track_id | string | yes | The candidate track you're mixing INTO — a catalog itunes_track_id. |
Structured output declared, but exposes no named fields.
No examples provided.
search_catalog Search Music Catalog ~355
Full-text search the catalog by any mix of track / artist / album tokens. Use this to resolve a fuzzy, partial, or misspelled name into concrete tracks BEFORE calling get_audio_features. Each hit carries `chart_peak`: the best chart position we hold, 1-100 with 100 = a number-one. `null` means no placement we hold — treat that as UNKNOWN, not unpopular, and note it is NOT an audience-size figure. Coverage is Billboard year-end only so far. Returns lightweight stubs (itunes_track_id, track_name, artist_name, album, etc.) ranked by relevance — NOT audio features. Take the best match's track_name + artist_name and pass them to get_audio_features, or reuse its itunes_track_id as a `track_id` seed for discovery tools. ⚠ Each hit carries a `seedable` boolean. Only a hit with `seedable: true` can be used as a seed for get_recommendations / suggest_next_track / build_setlist / score_transition — those work off the similarity index, which holds only tracks we have analysed, and about a quarter of the catalogue is not analysed yet. **Prefer the highest-ranked hit with `seedable: true`.** Seeding with a `seedable: false` id returns a 404; if that track is the one you want, call get_audio_features on it first to queue analysis, then retry.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Max results (default 10). |
| q | string | yes | Search query — any mix of artist / track / album tokens. |
Structured output declared, but exposes no named fields.
No examples provided.
suggest_next_track Suggest Next Track ~424
Given a seed track, return the top-N catalog tracks to play NEXT, ranked by transition score. Each suggestion carries the same `score`, per-component scores and human `reason` as score_transition (e.g. "11B->11B same key, 118->117 BPM (-0.29), energy +0.12"), plus its `genre` and `genre_relation` to the seed. GENRE-AWARE by default (cross_genre=auto): off-genre picks that only coincidentally share the seed's key/BPM sink to the bottom — use cross_genre=strict for same-genre-family only, or allow for the old harmonic-only ranking. It is the seed's sonic neighbours re-ranked for a clean mix. Returns `seed`, `count`, and a `suggestions` array of {track, score, components, reason}. seed_track_id is a catalog itunes_track_id from search_catalog or a get_audio_features result. Pair with build_setlist to order a whole crate. Costs 3 quota units.
| Name | Type | Req | Description |
|---|---|---|---|
| bpm_drift | number | – | Max BPM difference pre-filter before scoring (default 12). |
| cross_genre | string | – | Genre handling: 'auto' (default) keeps picks in a mixable genre lane so an off-genre track that only shares key/BPM sinks to the bottom; 'strict' = same genre-family only; 'allow' = genre-blind (harm… |
| exclude_same_artist | boolean | – | Drop tracks by the seed's artist (default false). |
| max_key_distance | integer | – | Max Camelot-wheel hops pre-filter before scoring (default 2). |
| min_score | integer | – | Drop candidates below this overall transition score (default 0). |
| n | integer | – | How many next-track suggestions to return (default 10). |
| seed_track_id | string | yes | The track currently playing — a catalog itunes_track_id. |
Structured output declared, but exposes no named fields.
No examples provided.
tag_track Tag Track ~635
Get a compact, HONESTLY-LABELLED tag list for a track — energy / danceability / valence / acousticness / instrumentalness, plus a mood tag and a broad genre tag. It is a tag-shaped projection of the same open-data analysis get_audio_features returns (no audio upload, no extra compute), so it costs the same 1 quota unit, charged only on a served result. The differentiator vs opaque taggers (e.g. Cyanite) is that EVERY tag carries its own `confidence` and `provenance`: - confidence: measured (our Essentia analysis) | derived (MIREX mood from valence+energy) | model-estimated (AcousticBrainz mood SVM probability — research-grade, raw prob in `value`) | catalog-genre (broad catalogue tag, not fine-grained). - provenance: essentia | valence+energy | acousticbrainz | catalog. `value` is the [0,1] score for numeric tags and null for label-only tags (mood category, genre). Provide AT LEAST ONE identifier: `track` (optionally with `artist`), `isrc`, `mbid`, `spotify_id`, or `track_id` (catalog itunes_track_id). If you know several, send them all — they resolve by precedence (`track` > `isrc` > `track_id` > `mbid` > `spotify_id`) and the rest are ignored, so you never have to pick. The broad, reliable coverage is the MEASURED tags from our Essentia analysis over the analysed catalogue (plus on-demand by name); MBID/ISRC additionally reach 7.5M+ AcousticBrainz recordings WHEN you supply that identifier. Returns { track, count, tags:[{tag, category, value, confidence, provenance}], disclaimer }. For the full numeric feature set use get_audio_features; for nearest tracks use a discovery tool.
| Name | Type | Req | Description |
|---|---|---|---|
| artist | – | – | Artist name. Only used with `track`; improves accuracy. |
| isrc | – | – | ISRC, e.g. 'USUM71900001'. |
| mbid | – | – | MusicBrainz recording ID (UUID). Tags come from AcousticBrainz for that exact recording. |
| spotify_id | – | – | 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 miss… |
| track | – | – | Track title. Use with `artist` when known. Supply AT LEAST ONE of track/isrc/mbid/spotify_id/track_id. Sending several is fine — they resolve by precedence (track > isrc > track_id > mbid > spotify_i… |
| track_id | – | – | Catalog itunes_track_id from a search_catalog or get_audio_features result. |
Structured output declared, but exposes no named fields.
No examples provided.
What is the FreqBlog Music Metadata MCP server?
FreqBlog Music Metadata is an MCP server listed in the public MCP registry as com.freqblog/music-metadata. Audio features + harmonic set-building for tracks by name/ISRC. Spotify audio-features replacement. This page covers its hosted endpoint (https://mcp.freqblog.com/mcp).
Is the FreqBlog Music Metadata MCP server safe to use?
FreqBlog Music Metadata scores 79 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the FreqBlog Music Metadata MCP server expose?
FreqBlog Music Metadata exposes 12 tools: get_audio_features, get_audio_features_batch, search_catalog, find_tracks_by_bpm, find_tracks_by_key, and 7 more. Their descriptions and schemas cost roughly 4,573 tokens of context every time the server is loaded.
Does the FreqBlog Music Metadata MCP server require authentication?
Yes. FreqBlog Music Metadata asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the FreqBlog Music Metadata MCP server still maintained?
FreqBlog Music Metadata is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.