FreqBlog Music Metadata
Server Details
Audio features (BPM, key, mood, genre) for real tracks - a Spotify audio-features replacement.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 12 of 12 tools scored.
Each tool serves a clearly distinct purpose: search, key/BPM filtering, feature extraction, transition scoring, set building, recommendations, artist relations, and tagging. No two tools overlap in functionality, and descriptions clarify any potential confusion.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., build_setlist, find_tracks_by_key). The verbs (build, find, get, score, search, suggest, tag) are appropriate and predictable, with no mixed conventions.
With 12 tools, the set is well-scoped for a music metadata and DJ mixing server. Each tool is justified and covers a specific operation without unnecessary redundancy or excessive bloat.
The tool surface comprehensively covers the domain: search, key and BPM queries, audio features (single and batch), transition scoring, set building, recommendations, related artists, and tagging. No obvious gaps exist for the stated purpose.
Available Tools
12 toolsbuild_setlistBuild SetlistARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| arc | No | Energy arc: 'peak_time' (default), 'warmup', 'cooldown', or 'flat'. | peak_time |
| track_ids | Yes | The crate to order — 2 to 100 catalog itunes_track_ids. | |
| start_track_id | No | Optional fixed opener — must be one of track_ids. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it discloses the energy arc options (peak_time default, warmup, cooldown, flat), quota cost (5 units), and return structure (flow_score, transitions, omitted tracks). Annotations only provide readOnlyHint and openWorldHint, which the description complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded: first sentence states purpose and constraints, second explains arc and returns, third adds usage tip and quota cost. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relatively simple tool with an output schema (true), the description fully compensates by detailing return fields (arc, count, flow_score, tracks, transitions, omitted) and providing usage guidance (feed track IDs into DJ software). No gaps in understanding remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the description, including defaults (arc default peak_time, start_track_id default null), constraints (track_ids 2-100, must be catalog itunes_track_ids), and behavior (start_track_id must be in track_ids). This adds meaning beyond the schema's description fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool orders a crate of tracks into a beat-matched DJ set, specifying the resource (catalog tracks), action (order/build), and scope (2-100 tracks with energy arc). It distinguishes from sibling tools like search_catalog or find_tracks_by_bpm by focusing on sequencing and mixing rather than individual track discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines usage: when you have a crate of tracks and want a harmonically and tempo-smooth set. It does not explicitly exclude alternatives or compare to siblings, but the purpose is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_compatible_keysFind Harmonically Compatible KeysARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| camelot | Yes | Camelot key, e.g. '8A' or '12B'. | |
| extended | No | Also return the +7/-7 energy-boost / energy-drop keys. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false, indicating safe, deterministic behavior. Description adds no contradiction and reinforces with 'pure music theory — no catalog lookup and no quota cost', providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first explains basic functionality, second covers the extended option, third provides nature and guidance. No extraneous information, well-structured and front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, full schema coverage, annotations, and an output schema, the description completes the picture by explaining the DJ mixing context and the Camelot wheel logic. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add parameter-level details beyond the schema, but it provides useful context for the extended parameter's effect (energy-boost/drop keys), which adds value beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns harmonically compatible keys for DJ mixing given a Camelot key. It distinguishes from siblings by noting it's pure music theory with no catalog lookup, and suggests pairing with find_tracks_by_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: for Camelot key compatibility analysis. States it's no catalog lookup and no quota cost, and recommends pairing with find_tracks_by_key to get actual tracks. This contrasts with sibling tools that likely involve catalog searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_tracks_by_bpmFind Tracks by BPMARead-onlyInspect
Find catalog tracks near a target tempo. Returns tracks whose BPM is within
+/-tolerance of bpm, ordered by closeness then popularity — 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 | Required | Description | Default |
|---|---|---|---|
| bpm | Yes | Target tempo in BPM. | |
| limit | No | Max tracks (default 10). | |
| tolerance | No | Plus/minus BPM window (default 2). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint: true), the description adds that results are ordered by closeness then popularity and that each track carries full audio features. It does not contradict annotations and provides useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence contributes meaning without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 simple parameters and an output schema exists, the description fully covers purpose, usage, ordering, and combination with related tools, leaving no gaps for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description explains how bpm, tolerance, and limit interact: 'within +/-`tolerance` of `bpm`' adds meaning beyond individual descriptions. However, the schema already describes parameters well, so the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find catalog tracks near a target tempo,' specifying the verb 'find' and resource 'catalog tracks.' It provides context about BPM tolerance, ordering by closeness and popularity, and use cases like DJ planning or tempo-matching, effectively distinguishing it from sibling tools like find_tracks_by_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use the tool ('useful for DJ set planning, workout playlists, or tempo-matching') and suggests combining with find_tracks_by_key for key constraints, offering clear guidelines and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_tracks_by_keyFind Tracks by Musical KeyARead-onlyInspect
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 popularity, each with full audio features. To
discover which keys mix well with a given key first, use find_compatible_keys.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Camelot ('8A'), Open Key ('1m'), or key name ('A-Minor', 'F#-Major'). | |
| limit | No | Max tracks (default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld, and description adds that results are ordered by popularity with full audio features. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences front-load purpose and key formats, then output ordering and sibling reference. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, full annotations, and presence of output schema, the description covers purpose, usage, key formats, output behavior, and sibling relation adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing descriptions for both parameters. The description reinforces key formats but adds no new parameter semantics beyond the schema, warranting baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds catalog tracks by musical key for harmonic mixing and key-locked playlists. It distinguishes from sibling find_compatible_keys by specifying this tool directly finds tracks by key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use find_compatible_keys first to discover which keys mix well, providing clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audio_featuresGet Audio FeaturesARead-onlyInspect
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 EXACTLY ONE identifier:
- `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.
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 queues an on-demand
analysis and this tool reports that it is queued — retry in ~30s-2min. If you only
have a fuzzy or partial name, call search_catalog first to find the exact track.
| Name | Required | Description | Default |
|---|---|---|---|
| isrc | No | ISRC, e.g. 'USUM71900001'. | |
| mbid | No | MusicBrainz recording ID (UUID). The precise key when there is no ISRC, e.g. pre-1986 recordings. | |
| track | No | Track title. Use with `artist` when known. Required field is ONE of track/isrc/mbid/spotify_id. | |
| artist | No | Artist name. Only used with `track`; required when the title is <=2 characters. | |
| spotify_id | No | Spotify track ID, 'spotify:track:...' URI, or open.spotify.com URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations, such as the on-demand analysis queuing and retry timing, and potential null fields for fallback tracks. It aligns with readOnlyHint and openWorldHint without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded output details, then usage instructions, then caveats. It is reasonably concise, though the first few sentences could be slightly tightened for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers all necessary contextual aspects: identifier options, fallback behavior, queuing, and when to search first. It is fully adequate for correct tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), and the description adds crucial context: exactly one identifier required, track optionally with artist, and artist required for short titles. This clarifies usage beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets audio features for one track, listing specific features like BPM, musical key, etc. It distinguishes itself from siblings by explicitly stating it's for a single track, contrasting with batch and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool, including the required identifier types and when to use search_catalog for fuzzy names. It implicitly excludes batch use by stating 'ONE track', but could be more explicit about not using for multiple tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audio_features_batchGet Audio Features (Batch)ARead-onlyInspect
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. For a single
track, use get_audio_features.
| Name | Required | Description | Default |
|---|---|---|---|
| tracks | 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`. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds critical behavioral context: it explains billing (only charged when features returned or on-demand ingest queued), error handling (bad entries don't fail batch), and the exact behavior for items over the limit ('over_limit' status) or missing query fields ('invalid_no_query').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with clear paragraph breaks. Every sentence adds value, and the most critical information (purpose and limit) is front-loaded. Could be trimmed slightly without losing substance, but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—batch processing, multiple query methods, limit handling, billing implications—the description is exhaustive. It covers all edge cases (over_limit, invalid_no_query, fallback logic) and references the output structure (counts and results array). The output schema exists but the description complements it well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant semantic meaning: it explains the ISRC exact-match priority, fallback mechanism, optional artist for name-match accuracy, limit of 50 processed per call, and the behavior of skipped items. The description clarifies how to properly structure queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get audio features for MANY tracks in one call' and specifies the tool is 'ideal for analysing a whole playlist at once.' It distinguishes from the sibling tool 'get_audio_features' by explicitly noting 'For a single track, use get_audio_features.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it explains when to use the batch tool (analysing playlists), how to handle limits (split long lists into calls of <=50), and explicitly contrasts with 'get_audio_features' for single track lookups. It also explains fallback behavior and which items are skipped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recommendationsGet RecommendationsARead-onlyInspect
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}). `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. seed_tracks are catalog
itunes_track_ids from search_catalog or the itunes_track_id field of a get_audio_features
result. Costs 2 quota units.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return (default 20). | |
| seed_tracks | Yes | 1-5 catalog itunes_track_ids to base recommendations on, e.g. ['apple_ad1829eeccb70f9a'] (blended into a feature-space centroid). | |
| exclude_seed_artists | No | Drop tracks by any of the seed artists (default false). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly and openWorld), it details cost, score semantics, ordering, seed format, and return fields. Fully discloses non-obvious behavior like genre affinity influencing order but not score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused paragraphs that front-load purpose. Slightly verbose in later parts, but every sentence adds value. Could tighten the re-ranking explanation without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage given tool complexity: explains inputs, return structure, cost, and algorithmic nuance. No gaps remain given that output schema exists and parameters are fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond the schema: explains seed_tracks format (itunes_track_ids from specific sources), blending behavior, and the effect of genre affinity on ordering. Schema coverage is already 100%, but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates recommendations from seed tracks and positions itself as a replacement for Spotify's endpoint. It distinguishes from siblings by focusing on recommendation generation rather than search or feature extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (given seed tracks) and outlines the algorithmic behavior (blending, re-ranking). However, it does not explicitly exclude alternatives or compare with similar tools like suggest_next_track.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_transitionScore TransitionARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| to_track_id | Yes | The candidate track you're mixing INTO — a catalog itunes_track_id. | |
| from_track_id | Yes | The track you're mixing FROM — a catalog itunes_track_id, e.g. 'apple_ad1829eeccb70f9a'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=true. Description adds valuable behavioral details: returns per-component scores, detail block, human reason, and costs 1 quota unit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: front-loaded purpose, then return values, then sourcing, then costing. Each sentence adds value. Slight marketing language ('no raw key/BPM API gives you') could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity of scoring tool, description covers purpose, input sourcing, return structure (including example reason), and costing. Output schema exists to detail return format, so description is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with clear parameter descriptions. Description adds extra context: confirms both are catalog itunes_track_ids and provides sourcing guidance. Baseline 3 increased due to added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Score how well one catalog track mixes into another (0-100)' – a specific verb+resource. It distinguishes from siblings like find_compatible_keys and suggest_next_track by focusing on pairwise transition scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent where to get input IDs ('from search_catalog or the itunes_track_id field of a get_audio_features result'). Provides clear context for when to use, but could explicitly state when not to use (e.g., if only key info needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogSearch Music CatalogARead-onlyInspect
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query — any mix of artist / track / album tokens. | |
| limit | No | Max results (default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it returns stubs ranked by relevance, not audio features. Annotations already declare readOnlyHint and openWorldHint, so the description complements them. Missing details like pagination or sorting, but overall sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences. The first sentence immediately states the action (search). The second sentence gives usage context. The third sentence details return type and next steps. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description provides complete context: explains what the tool does, when to use it, what it returns, and how to proceed. It effectively covers the tool's role in a workflow without omitting critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (q and limit) with high coverage (100%). The tool description does not add new parameter information beyond repeating the schema's description for q. Therefore, it adds minimal value, meeting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search on a music catalog by track, artist, or album tokens. It distinguishes itself from siblings by explicitly contrasting with get_audio_features and mentioning that it returns lightweight stubs, not audio features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this to resolve a fuzzy, partial, or misspelled name into concrete tracks BEFORE calling get_audio_features.' It also provides clear next steps and alternatives, such as passing the result to get_audio_features or reusing the itunes_track_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_next_trackSuggest Next TrackARead-onlyInspect
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"). 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 | Required | Description | Default |
|---|---|---|---|
| n | No | How many next-track suggestions to return (default 10). | |
| bpm_drift | No | Max BPM difference pre-filter before scoring (default 12). | |
| min_score | No | Drop candidates below this overall transition score (default 0). | |
| seed_track_id | Yes | The track currently playing — a catalog itunes_track_id. | |
| max_key_distance | No | Max Camelot-wheel hops pre-filter before scoring (default 2). | |
| exclude_same_artist | No | Drop tracks by the seed's artist (default false). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the output format (seed, count, suggestions array with track, score, components, reason), cost (3 quota units), and input requirements. It aligns with annotations (readOnlyHint, openWorldHint) and adds behavioral details beyond annotations, such as the pre-filtering logic and the 'reason' string format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 6 sentences, front-loading the core purpose and then efficiently covering output format, input details, sibling tool pairing, and cost. Every sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to understand and invoke the tool correctly. It explains the tool's purpose, input source, output structure, cost, and a related tool (build_setlist). Given the existence of an output schema and high schema coverage, the description provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in the schema with descriptions (100% coverage), so the baseline is 3. The description adds value by explaining that bpm_drift and max_key_distance act as pre-filters before scoring and that seed_track_id comes from specific sources, which enhances the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a seed track and returns the top-N catalog tracks ranked by transition score. It distinguishes from siblings like score_transition (which provides a pairwise score) and find_compatible_keys, and specifies the input source (catalog itunes_track_id from search_catalog or get_audio_features).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests pairing with build_setlist and mentions it uses the same scoring as score_transition, providing implicit usage context. However, it does not explicitly contrast with alternatives or specify when not to use this tool, which would have made it more complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tag_trackTag TrackARead-onlyInspect
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 EXACTLY ONE identifier: `track` (optionally with `artist`), `isrc`, `mbid`,
`spotify_id`, or `track_id` (catalog itunes_track_id). 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 | Required | Description | Default |
|---|---|---|---|
| isrc | No | ISRC, e.g. 'USUM71900001'. | |
| mbid | No | MusicBrainz recording ID (UUID). Tags come from AcousticBrainz for that exact recording. | |
| track | No | Track title. Use with `artist` when known. Required field is ONE of track/isrc/mbid/spotify_id/track_id. | |
| artist | No | Artist name. Only used with `track`; improves accuracy. | |
| track_id | No | Catalog itunes_track_id from a search_catalog or get_audio_features result. | |
| spotify_id | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds beyond annotations: it explains the cost model (1 quota unit, charged only on served result), the derivation of tags (Essentia, MIREX, etc.), and the presence of confidence and provenance fields. This complements the readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and informative, but slightly lengthy. However, every sentence adds value, and it is organized logically. Could be slightly more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, output schema present), the description covers purpose, usage, behavior, and parameters comprehensively. It references sibling tools and provides enough context for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the input schema (100% coverage), and the description adds meaningful context: it specifies that exactly one identifier is required, explains when to use each identifier, and notes that artist is only used with track.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a compact, HONESTLY-LABELLED tag list for a track', listing specific tags (energy, danceability, etc.) and distinguishing itself from opaque taggers like Cyanite. It also mentions alternative tools for full features or nearest tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives ('For the full numeric feature set use get_audio_features; for nearest tracks use a discovery tool'), explains the required identifier format, and clarifies coverage differences between identifiers (e.g., MBID/ISRC reach AcousticBrainz recordings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!