Retrieves physical pressings, reissues, and edition details from Discogs.
Provides album search and per-track performer/production credits via MusicBrainz, keyed on MBID.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@king-crimson-mcp What incarnation does Elephant Talk belong to?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
日本語版: README.ja.md
An MCP server that surfaces King Crimson record and live-performance data — including a curated incarnation (line-up era) model that shows how each song belongs to specific eras of the band.
Generic MusicBrainz/Discogs MCP servers can already fetch releases, credits, and pressings. This server does that too, but adds two things a band-agnostic discography tool structurally can't have:
A cross-source integration layer keyed on MBID. MusicBrainz, Discogs, Cover Art Archive, and setlist.fm are stitched together so one release-group MBID gets you credits, physical editions, artwork, and live history without re-resolving identities per source.
A King Crimson incarnation model. King Crimson's line-up turned over almost completely, many times, over five decades — the same song can mean a totally different band depending on the year. This server hand-curates eight line-up eras and cross-references every tracked song's live-performance history against them:
Song | Incarnations it appears in |
"21st Century Schizoid Man" | Spread across every era — the band's signature |
"Starless" | Only the Larks' Tongues era and the Three-drummer era |
"Elephant Talk" | Born in the Discipline era, gone by the Three-drummer era |
A local, offline-first concert cache. Full concert history (1,200+ shows) is fetched once via refresh_setlist_cache and cached as JSON. Every subsequent song/tour/era query reads the cache — instant, and immune to setlist.fm's intermittent rate-limit failures during analysis.
Reverse lookup: song → the live albums that captured it, by era. Ask "which live releases contain Red?" and get them grouped by incarnation. It cross-references two things this server already knows — when a song was played (from the setlist cache) and when each official live album was recorded (parsed from its title) — so it answers a question neither MusicBrainz nor Discogs answers directly.
For Red, this surfaces 37 single-show live albums across the Discipline, THRAK, ProjeKcts and Three-drummer eras — and correctly shows none from the 1974 line-up that recorded it, which never played it live (numbers as of this writing; MusicBrainz's catalog can grow).
Related MCP server: spotify-mcp
Tool | Description |
| MusicBrainz album search → MBIDs |
| Per-track performer/production credits, resolved at the recording level, plus a deduplicated album roster |
| Physical pressings/reissues via Discogs, preferring the exact MusicBrainz→Discogs relation over fuzzy search |
| Cover art via the Cover Art Archive |
| One-page setlist.fm search by venue/city/year (no cache needed) |
| Fetch and cache an artist's complete concert history from setlist.fm |
| A song's live history from the cache: |
| The curated line-up eras — members, instruments, key releases |
| Fetch King Crimson's official live releases from MusicBrainz and cache them, parsing a recording date from each title |
| Find official live releases that captured a song, grouped by incarnation — matches the setlist cache against live-release recording dates |
| Fetch King Crimson's compilations and box sets from Discogs and cache their tracklists |
| List box sets / compilations that contain a given song (from Discogs), with year, format, Discogs URL, and occurrence count |
Eight line-up eras, split on membership changes:
id | Era | Years |
| In the Court era | 1969 |
| Transitional era | 1970 – Sep 1972 |
| Larks' Tongues era | Oct 1972 – 1974 |
| Discipline era | 1981 – 1984 |
| Double Trio / THRAK era | 1994 – 1996 |
| ProjeKcts / Nuovo Metal era | 1997 – 2003 |
| 40th Anniversary era | 2008 |
| Three-drummer era | 2014 – 2021 |
Boundaries are dates, not just years — 1972 in particular splits into the Islands-era "Earthbound" spring tour (Transitional) and the Wetton-era autumn tour (Larks' Tongues), since the band's membership genuinely changed mid-year.
Line-up eras are a matter of fan interpretation, and this is one reasonable cut, not the only one. The full definition lives in KING_CRIMSON_INCARNATIONS in src/king_crimson_mcp/server.py — edit it (members, key releases, date boundaries) to match your own view; the aggregation logic doesn't need to change.
"Which releases have Red on them?" is answered in two complementary ways, because King Crimson's live catalog splits cleanly into single-show albums and multi-show compilations.
song_live_releasesNeeds two local caches, built once:
refresh_setlist_cache — every show and what was played (already covered above).
refresh_live_releases_cache — King Crimson's official live releases from MusicBrainz, with a recording date parsed out of each title where possible.
Both are one-time builds: the band's history is fixed, so neither cache needs to be rebuilt unless you want to pick up new MusicBrainz entries.
How it works: a song's performance dates come from the setlist cache; each live release carries a recording date parsed from its title (e.g. "Live in Toronto – June 24, 1974"). Where a release's recording date matches a date the song was played, that release is taken to contain the song. This is a straightforward, transparent rule — reliable for single-show live albums.
Known limits (by design): King Crimson has about 187 official live releases, of which only about 87 (as of this writing) have a title MusicBrainz-parseable into a full recording date — that's the range song_live_releases can match with confidence. The other ~100 (box sets, compilations, titles without a date) can't be matched this way; song_live_releases reports exactly how many were skipped in its coverage field rather than silently under-reporting. Excerpt compilations are an edge case too: a song played at a show can, in principle, be matched to that show's release even if the specific release is a highlights disc that omits the track — date-matching can't distinguish "recorded that night" from "included on the disc."
song_box_setsThe multi-show box sets and compilations that song_live_releases can't date-match are covered here, from Discogs. It filters King Crimson's Discogs releases to compilations and box sets (format contains "Comp" or "Box" — which excludes single-show downloads) and lists the ones whose tracklist contains the song: title, year, format, Discogs link, and how many times the song appears on each.
Why no era grouping here: Discogs doesn't structure per-track recording dates, so a box set can't be split into eras the way single-show albums can. song_box_sets therefore lists the box sets containing a song rather than classifying them — era-level precision is song_live_releases's job. Together they cover both halves of the question.
Needs its own one-time cache: run refresh_box_sets_cache (about a minute; ~38 box sets/compilations from Discogs, as of this writing). Requires DISCOGS_TOKEN.
For Red, song_box_sets returns 14 box sets/compilations (the "Collectors' King Crimson" volumes, "1972–1974", the "2015 Japan Tour Box", …), while song_live_releases handles the single-show side.
The honesty of both tools' coverage reporting is the point: results are exactly as complete as the underlying data lets them be, and you (or the calling agent) can see where to dig further instead of getting a silently incomplete answer.
Three one-time steps, then it runs inside Claude.
uv (one time)uv is a small tool that can fetch and run this server for you.
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows (PowerShell):
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"Close and reopen your terminal afterward. To check it worked:
uv --versionThis server reads public music databases. Two of them need a free key:
setlist.fm (live performance history) — apply for a key at https://api.setlist.fm/docs/1.0/index.html
Discogs (physical editions) — create a token at Discogs → Settings → Developers → Generate token
You also set a contact email (MCP_CONTACT) — MusicBrainz requires this so
their servers know who's calling. Any email you own is fine.
(MusicBrainz and Cover Art Archive need no key.)
Open Claude Desktop's config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add this (fill in your email and keys):
{
"mcpServers": {
"king-crimson": {
"command": "uvx",
"args": ["king-crimson-mcp"],
"env": {
"MCP_CONTACT": "you@example.com",
"SETLISTFM_API_KEY": "your-setlistfm-key",
"DISCOGS_TOKEN": "your-discogs-token"
}
}
}
}Restart Claude Desktop. King Crimson tools will appear automatically — you don't run anything in a terminal yourself.
In Claude, ask something like "Refresh the King Crimson setlist cache" once (it downloads the full concert history, ~40 seconds). After that, try "Show me the performance history of Starless" or "Which incarnations played 21st Century Schizoid Man?"
"uvx: command not found" / server won't start in Claude Desktop.
uv isn't installed or isn't on your PATH. Redo Step 1, then fully quit and
reopen Claude Desktop. On Windows you may need the full path to uvx in the
command field.
A warning appears if you run it manually in a terminal.
Running uvx king-crimson-mcp directly just waits silently for a client —
that's normal (it speaks over stdin/stdout). You don't need to run it by hand;
Claude Desktop starts and stops it for you. Press Ctrl+C to stop.
get_editions / setlist tools return an error about a missing key.
That tool's API key isn't set in your config's env block. See Step 2.
setlist data looks incomplete for older tours. setlist.fm is user-submitted; some historical shows or songs simply aren't logged there. This is a data limitation, not a bug.
For developers — the same package as Quick start above, without the Claude Desktop config:
# run directly without installing (recommended)
uvx king-crimson-mcp
# or install as a persistent tool
pipx install king-crimson-mcp
king-crimson-mcpSecrets (MCP_CONTACT, DISCOGS_TOKEN, SETLISTFM_API_KEY) go either in a .env file in the directory you run the command from, or directly in the Claude Desktop config's env block (see below) — either is read. .env is loaded from the current working directory, since an installed package has no project directory of its own to keep one in.
# Python 3.10+ required (3.12 recommended)
uv venv --python 3.12
source .venv/bin/activate
uv pip install -e .
# configure secrets
cp .env.example .env
# then edit .env.env variables:
MCP_CONTACT — required by MusicBrainz policy; identifies your app to their API via the User-Agent header.
DISCOGS_TOKEN — needed for get_editions (Discogs personal access token).
SETLISTFM_API_KEY — needed for get_live_history, refresh_setlist_cache, and song_performance_history.
KC_CACHE_DIR — optional; overrides where the setlist cache is written (see below).
# quick tool check via MCP Inspector
mcp dev src/king_crimson_mcp/server.pyRun refresh_setlist_cache once first — it fetches King Crimson's full concert history (~1,200 shows, ~40 seconds) and caches it locally under $XDG_CACHE_HOME/king-crimson-mcp (or ~/.cache/king-crimson-mcp; override with KC_CACHE_DIR) as setlists_<artist_mbid>.json. After that, song_performance_history reads from the cache and returns instantly.
Run refresh_live_releases_cache once as well if you want song_live_releases — it writes live_releases_<artist_mbid>.json alongside the setlist cache, in the same directory. refresh_box_sets_cache similarly writes box_sets_<artist_mbid>.json there, for song_box_sets.
Using the published package:
{
"mcpServers": {
"king-crimson": {
"command": "uvx",
"args": ["king-crimson-mcp"],
"env": {
"MCP_CONTACT": "you@example.com",
"DISCOGS_TOKEN": "...",
"SETLISTFM_API_KEY": "..."
}
}
}
}Or, running from a local clone instead (after uv pip install -e ., which installs the same king-crimson-mcp console script into the venv):
{
"mcpServers": {
"king-crimson": {
"command": "/absolute/path/to/.venv/bin/king-crimson-mcp",
"env": { "MCP_CONTACT": "you@example.com" }
}
}
}Secrets can live in .env (in the directory the command is run from) instead of the env block — either is read.
This project is an unofficial client with no affiliation with or endorsement from MusicBrainz, the MetaBrainz Foundation, the Internet Archive, Discogs, or setlist.fm.
MusicBrainz — free, no API key. Requires an identifying User-Agent with contact info (rate limit: 1 req/sec). Data is largely CC0; crediting MusicBrainz in your app is good practice. refresh_live_releases_cache also uses this: it lists King Crimson's official live release groups (type=live) — no additional service or key involved.
Cover Art Archive — a joint MusicBrainz / Internet Archive project. Images are contributed by individual uploaders; follow the same attribution etiquette as MusicBrainz.
Discogs — requires a personal access token and a unique User-Agent (60 req/min authenticated). Use is subject to the Discogs API terms of service. song_box_sets uses the same Discogs API as get_editions (no additional service or key).
setlist.fm — requires an API key (apply at api.setlist.fm). Any display of setlist.fm data must include an attribution link to the source setlist — every performance returned by this server includes its url for exactly that purpose; surface it wherever you show the data. setlist.fm data is user-submitted, so completeness and accuracy are not guaranteed.
setlist.fm data is user-submitted — some shows or songs may be missing or incorrect, especially from older tours.
The incarnation boundaries are one interpretation of King Crimson's line-up history, not an official taxonomy.
Performer credits depend on what MusicBrainz has cataloged for a given release; sparser releases yield sparser credits.
song_live_releases can only match live releases whose title yields a full recording date (about half of King Crimson's ~187 official live releases); see Song → releases above for what's out of reach and why.
song_box_sets can't classify box sets by incarnation — Discogs doesn't structure per-track recording dates, so it lists matching box sets/compilations rather than era-grouping them. A handful of the ~38 compilations it scans are multi-artist collections where King Crimson contributed only one track; these can surface as noise for very common song titles.
MIT — see LICENSE.
Get cover art for a release group from the Cover Art Archive.
Args:
mbid: MusicBrainz release-group ID (from search_release).
Returns:
A dict with an images list of {front, back, thumbnails, url}.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return structure but does not disclose edge-case behaviors such as handling of missing artwork or invalid IDs, which limits transparency.
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 and well-structured with Args and Returns sections. Every sentence provides value, with no redundancy or fluff.
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?
With no output schema, the Returns section adequately describes the response format. However, it omits potential error conditions or empty results, leaving a small but acceptable gap for a simple tool.
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 Args section explains that mbid is a 'MusicBrainz release-group ID' and refers to 'search_release', adding meaningful context beyond the bare schema. This fully compensates for the 0% schema description coverage.
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 a specific action: 'Get cover art for a release group from the Cover Art Archive.' This distinctly separates it from sibling tools like get_credits or get_editions by focusing on artwork retrieval.
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 provides clear context by specifying that mbid comes from 'search_release', indicating a prerequisite workflow step. While not explicitly excluding alternatives, the context is sufficient for an agent to understand when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performer and production credits for an album (release group).
Returns the headline artist credit and release-group relationships, plus per-track performer credits resolved from the recording level in MusicBrainz (individual musicians and their instruments), and a deduplicated album roster.
Args:
mbid: MusicBrainz release-group ID (from search_release).
release_mbid: Optional specific release (edition) to read track credits
from. If omitted, a representative official release is chosen.
Returns: A dict with title, artist_credit, release_used, performers (roster), tracks (per-track credits), relations, and external_links.
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | ||
| release_mbid | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains that per-track credits are 'resolved from the recording level in MusicBrainz,' includes a 'deduplicated album roster,' and describes the selection logic when release_mbid is omitted. This goes beyond a generic 'get' and gives meaningful insight into underlying processes.
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 efficiently structured with separate Args and Returns sections, front-loading the primary purpose. It contains no redundant phrasing, though it is longer than necessary for a simple getter. The extra detail is justified by the need to explain resolution logic and parameters.
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 self-contained: it explains the main purpose, parameter origins and defaults, and lists the exact keys in the returned dict. Since there is no output schema and no annotations, the description carries the full burden and fulfills it, making the tool's behavior and inputs clear enough for an agent to 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?
The input schema has no descriptions (0% coverage), so the description fully compensates by explaining mbid as 'MusicBrainz release-group ID (from search_release)' and release_mbid as an optional specific release with a clear fallback behavior. This provides complete semantic meaning beyond the raw type information.
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 starts with a specific verb and resource: 'Get performer and production credits for an album (release group).' It clearly distinguishes the tool from siblings like search_release, get_artwork, and get_live_history by focusing on credit resolution from MusicBrainz recording levels.
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 Args section states that mbid comes from search_release, providing a clear use case and workflow context. It also explains the optional release_mbid and the fallback to a representative official release, giving practical guidance. It does not explicitly list when not to use the tool, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List physical editions/pressings of an album via Discogs.
Resolves the Discogs master for the album -- preferring the discogs
relation stored on the MusicBrainz release group (exact match), and
falling back to a Discogs title/artist search when no such relation
exists. Then lists the master's versions (pressings, reissues, box sets)
with format, country, year and community stats. Requires DISCOGS_TOKEN.
Args:
mbid: MusicBrainz release-group ID (from search_release).
max_versions: Max editions to return (1-50).
Returns:
A dict with master info and a versions list. match_method
reports how the master was resolved ("musicbrainz-relation" or
"discogs-search").
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | Yes | ||
| max_versions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the resolution strategy, requires DISCOGS_TOKEN, and describes the returned fields and match_method. It stops short of error handling or rate limits, but provides solid behavioral context beyond a simple list.
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-organized with clear sections for intro, resolution logic, args, and returns. It is succinct without fluff; every sentence adds value and is front-loaded with the primary purpose.
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?
For a two-parameter tool with moderate complexity, the description covers the resolution algorithm, required token, input parameters, and return structure. It is complete enough for an agent to invoke correctly, despite lacking an output schema.
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 description coverage is 0%, but the description includes an Args section explaining mbid as a MusicBrainz release-group ID from search_release and max_versions as a range (1-50). This adds essential semantics beyond the bare schema, making the parameters clear.
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 lists physical editions/pressings of an album via Discogs, using a specific verb ('List') and resource. It distinguishes from siblings by detailing the Discogs master resolution process, making its purpose distinct from other album-related 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 explains that the mbid comes from search_release and describes the resolution logic (preferring a Discogs relation, falling back to search). However, it does not explicitly contrast with sibling tools like get_incarnations or song_box_sets, leaving when-to-use vs alternatives implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List King Crimson's line-up eras (incarnations): id, name, date range, members with instruments, key releases, and a one-line note.
Use this to look up who played in a given era. Song analysis
(song_performance_history) reports per-era counts under by_incarnation
keyed by the same ids/names, so this is the reference for those.
Returns:
A dict with an incarnations list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the return shape ('A dict with an `incarnations` list') and the fields included, but does not mention ordering, completeness, or error behavior. For a simple list tool, this is adequate but not exhaustive.
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 short paragraphs with no redundant information. Each section (overview, usage, returns) serves a distinct purpose and every sentence earns its place.
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 0 params and no output schema, the description provides enough detail about the output structure and the tool's role relative to a sibling tool. It could include an example but is not necessary for a straightforward list tool; the description is complete for its complexity.
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?
There are zero parameters, so the schema and description have nothing to clarify. Baseline of 4 applies as there is no parameter information to miss.
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 opens with a clear verb 'List' and specifies the resource 'King Crimson's line-up eras (incarnations)', followed by an enumeration of returned fields. It also distinguishes itself from the sibling `song_performance_history` by positioning itself as the reference for incarnation IDs/names.
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 states 'Use this to look up who played in a given era' and references the sibling `song_performance_history` to note that its per-era counts are keyed by the same IDs/names, making this tool the lookup reference. This gives clear when-to-use guidance and points to an alternative for related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live performance history / setlists via setlist.fm.
Useful for King Crimson given their extensive touring: cross-reference official live albums against what was actually played on a given tour. Requires SETLISTFM_API_KEY.
Args: query: Optional venue or city keyword to narrow the search. artist: Artist name. Defaults to "King Crimson". year: Optional year filter. limit: Max setlists to return (1-20; one API page).
Returns:
A dict with a setlists list of {date, venue, city, country, songs}.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| query | No | ||
| artist | No | King Crimson |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the required SETLISTFM_API_KEY, describes the return format as a dict with a setlists list, and notes that the limit parameter maps to a single API page. It doesn't mention rate limits or explicitly confirm read-only behavior, but the 'Search' verb implies a safe operation.
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 appropriately sized: a brief summary, a motivational use case, an API key note, a clear Args list, and a Returns section. Every sentence adds value, and the format is front-loaded with the main purpose.
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?
Despite lacking an output schema and annotations, the description covers all essential aspects: the return format, parameter semantics, and a prerequisite API key. The inclusion of the setlist structure (date, venue, city, country, songs) makes it fully self-contained for a search tool.
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?
Since the schema has 0% description coverage, the description fully compensates by explaining each parameter: query (optional venue/city keyword), artist (defaults to King Crimson), year (optional filter), and limit (max setlists, 1-20, one API page). This is comprehensive and adds significant meaning beyond the bare schema.
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 function: 'Search live performance history / setlists via setlist.fm.' This uses a specific verb and resource, and the context about King Crimson differentiates it from sibling tools like song_performance_history, which target individual song histories.
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 context: 'Useful for King Crimson given their extensive touring' and notes the API key requirement. However, it does not explicitly name alternative tools or state when not to use this tool, stopping short of full alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch King Crimson's compilations and box sets from Discogs and cache their tracklists, so song_box_sets can list which box sets contain a song.
Filters the artist's Discogs releases to Main-role compilations/box sets (format contains "Comp" or "Box"), which excludes single-show live downloads (those are covered by song_live_releases). Requires DISCOGS_TOKEN.
Returns: A summary: releases scanned, box sets cached, and the cache path.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 | |
| discogs_artist_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the network fetch, caching side effect, filtering rule, required DISCOGS_TOKEN, and return summary. It does not explain overwrite/destructive behavior or rate limits, but it covers the key behavioral traits for using the tool safely.
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 into purpose, filtering/exclusion/token note, and return summary. Every sentence adds useful information with no fluff or repetition, and the key purpose is front-loaded.
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 covers the tool's purpose, filtering, exclusion, auth requirement, and return output despite no output schema. It falls short only in not explaining the force parameter, which is a meaningful gap for correct invocation.
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 description coverage is 0%, and the description does not compensate. It mentions the artist context but never explains the force parameter or the roles of artist_mbid/discogs_artist_id beyond what the schema names imply. 'force' is left completely ambiguous.
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 states a specific action: fetch King Crimson's compilations/box sets from Discogs and cache their tracklists for use by song_box_sets. It clearly distinguishes from siblings like song_live_releases and refresh_live_releases_cache by scoping to Main-role compilations/box sets.
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 this refresh supports song_box_sets lookups and excludes single-show live downloads, which are covered by song_live_releases. This provides both a clear when-to-use and an explicit alternative, making the usage context strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch King Crimson's official live releases from MusicBrainz and cache them locally, parsing a recording date out of each title where possible.
Used by song_live_releases to map songs to the live albums that captured them. King Crimson's live catalog is fixed, so this rarely needs re-running. Requires MCP_CONTACT (MusicBrainz User-Agent policy).
Args: artist_mbid: MusicBrainz artist MBID. Defaults to King Crimson. max_pages: Safety cap on pages to fetch (100 release groups/page). max_retries: Retries per page on transient error (e.g. MusicBrainz's intermittent 503s) before giving up. force: Re-fetch even if a cache file already exists.
Returns: A summary: totals, how many titles yielded a full recording date, and the cache path.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| max_pages | No | ||
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 | |
| max_retries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that the tool makes network requests to MusicBrainz, adheres to the User-Agent policy via MCP_CONTACT, caches results locally, can force re-fetching, and returns a summary with totals and cache path. It also mentions retry behavior for transient errors.
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: a concise summary, usage context, requirements, parameter list, and return description. Every sentence adds value without verbosity.
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 lack of an output schema, the description includes a Returns section detailing the summary contents. It covers purpose, prerequisites, parameters, and behavior, making it self-contained for an AI agent to decide when and how to call this tool.
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 schema provides only types and defaults with zero descriptions. The description's Args section explains each parameter: artist_mbid (defaults to King Crimson), max_pages (safety cap), max_retries (retry on transient errors), and force (re-fetch even if cache exists). This fully compensates for the lack of schema descriptions.
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 fetches King Crimson's official live releases from MusicBrainz and caches them locally, parsing recording dates. This distinguishes it from sibling cache tools (refresh_setlist_cache, refresh_box_sets_cache) by focusing on live releases and mentioning its role in song_live_releases.
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 says it is used by song_live_releases to map songs to live albums, and notes that the live catalog is fixed so it rarely needs re-running. This provides clear context for when to invoke it, though it does not explicitly discuss alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an artist's complete concert history from setlist.fm and cache it locally as JSON, so song/tour analysis runs instantly and offline.
Robust against setlist.fm's intermittent failures: each page is retried with backoff, and any page that still fails is recorded rather than aborting the whole run. King Crimson's history is fixed (band ended 2021), so this rarely needs re-running. Requires SETLISTFM_API_KEY.
Args: artist_mbid: MusicBrainz artist MBID. Defaults to King Crimson. max_pages: Safety cap on pages to fetch (20 shows/page). max_retries: Retries per page on transient error before recording it failed. force: Re-fetch even if a cache file already exists.
Returns: A summary dict (not the setlists themselves): counts, coverage, any failed pages, date range, and the cache file path.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| max_pages | No | ||
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 | |
| max_retries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses important behaviors: retries with backoff against setlist.fm failures, records failed pages instead of aborting, requires SETLISTFM_API_KEY, caches locally as JSON, and returns a summary dict rather than the setlists themselves. These details go well beyond the basic function.
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-organized: a front-loaded purpose statement, a robustness note, an args section, and a returns section. Every sentence adds value, and the length is proportional to the tool's complexity. No fluff or repetition.
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?
With 4 parameters, no annotations, and no output schema, the description addresses all essential aspects: purpose, side effects, parameter details, failure behavior, and return value. It even clarifies that the return is a summary, not the setlists, which is important given the tool's name. The description is complete for successful agent invocation without further assumptions.
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 description coverage is 0%, but the description fully compensates by explaining each parameter's role: artist_mbid (MusicBrainz ID, defaults to King Crimson), max_pages (safety cap with 20 shows/page), max_retries (per page on transient errors), and force (re-fetch even if cache exists). This adds clear meaning beyond the schema's simple names and defaults.
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: fetch an artist's complete concert history from setlist.fm and cache it locally as JSON for instant/offline analysis. It distinguishes the tool from siblings by specifying the data source and cache target, and adds context about when it's needed (rarely, since King Crimson's history is fixed).
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 context for when to use the tool ('so song/tour analysis runs instantly and offline') and notes that it 'rarely needs re-running' due to the band ending in 2021. However, it does not explicitly mention alternatives among sibling cache-refresh tools (e.g., refresh_live_releases_cache) or when not to use it, so it falls short of fully explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MusicBrainz for release groups (albums) matching a query.
A "release group" is the canonical album, independent of its many physical
editions -- the right granularity for browsing a discography. Use the
returned mbid with the other tools.
Args: query: Free-text album title or keywords (e.g. "Red", "Larks' Tongues"). artist: Restrict to this artist. Defaults to "King Crimson". limit: Max results (1-25).
Returns:
A dict with a results list of {mbid, title, primary_type,
first_release_date, disambiguation}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| artist | No | King Crimson |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the search is read-only, explains the concept of release groups, and clearly describes the return structure. It does not mention rate limits, result ordering, or error behavior, but for a search tool this level of transparency is strong.
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: a brief opening that defines the resource, followed by Args and Returns sections. Every sentence adds value—the release group definition, the workflow hint, and the parameter/return details. It is neither overly verbose nor under-specified.
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?
With no output schema, the description fully explains the return value format. It covers the search concept, all parameters, and how to use the results. Given the tool's simplicity and the richness of the sibling context, the description is complete enough for an agent to select and invoke it 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?
Schema description coverage is 0%, so the description must compensate. The 'Args' section thoroughly explains each parameter: query (free-text title with examples), artist (restrict to this artist, with default), and limit (max results 1-25). This adds substantive meaning beyond the schema's basic type/default definitions.
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: searching MusicBrainz for release groups (albums) matching a query. It uses a specific verb ('search'), identifies the resource ('release groups'), and distinguishes itself from sibling tools (which are all get_* operations) by being the sole search tool and by instructing to use the returned mbid with other 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 implies when to use the tool: 'Use the returned mbid with the other tools' establishes a discovery-first workflow, and the release group granularity is explicitly positioned for browsing a discography. It does not explicitly exclude alternatives when an mbid is already known, but the context makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List King Crimson box sets / compilations that contain a given song (from Discogs). Complements song_live_releases: that tool maps single-show live albums to eras; this one covers the multi-show box sets and comps that date-matching can't resolve.
Run refresh_box_sets_cache first.
Args: song: Song title (e.g. "Red"). artist_mbid: MusicBrainz artist MBID (cache key). Defaults to King Crimson. match: "exact" (case-insensitive full track title) or "contains".
Returns: The box sets/compilations whose tracklist includes the song, with title, year, format, Discogs URL, and how many times the song appears on each.
| Name | Required | Description | Default |
|---|---|---|---|
| song | Yes | ||
| match | No | exact | |
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It reveals the data source (Discogs), the dependency on a cache refresh, the matching modes ('exact' vs 'contains'), and the return details including how many times the song appears. This is rich behavioral context beyond just 'this lists box sets.'
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 clear sections for purpose, complementary usage, prerequisites, args, and returns. Every sentence adds value: the example, the cache instruction, the match semantics, and the return fields. It is concise for the amount of guidance provided, with no filler or redundant restating of the tool name.
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 tool has 3 parameters, no output schema, and no annotations, yet the description covers all of these gaps: it documents every parameter, describes the return structure (title, year, format, Discogs URL, occurrence count), and gives the necessary cache-refresh prerequisite. In the context of the sibling tool list, this is a complete and self-sufficient description.
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 description coverage is 0%, but the description fully compensates. It explains each parameter with examples and semantics: song ('Song title (e.g. "Red")'), artist_mbid ('MusicBrainz artist MBID (cache key). Defaults to King Crimson'), and match ('exact (case-insensitive full track title) or contains'). This gives the agent everything needed to set parameters correctly.
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 opens with a specific verb, resource, and scope: 'List King Crimson box sets / compilations that contain a given song (from Discogs).' It immediately distinguishes itself from the sibling tool song_live_releases, stating that this tool covers multi-show box sets and comps, while the other maps single-show live albums. This is a clear, well-scoped purpose statement.
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 names the complementary tool song_live_releases and explains the division of labor: 'that tool maps single-show live albums to eras; this one covers the multi-show box sets and comps that date-matching can't resolve.' It also states a required prerequisite: 'Run refresh_box_sets_cache first.' This gives an agent explicit when-to-use and operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find official live releases that captured a given song, grouped by incarnation (line-up era).
How it works: the song's performance dates come from the setlist cache; live releases carry a recording date parsed from their title. Where a release's recording date matches a date the song was played, that release is taken to contain the song. This is authoritative for single-show live albums; excerpt compilations are an edge case.
Requires both caches: run refresh_setlist_cache and refresh_live_releases_cache first.
Args: song: Song title (e.g. "Red"). artist_mbid: MusicBrainz artist MBID. Defaults to King Crimson. match: "exact" (case-insensitive full title) or "contains" (substring).
Returns: by_incarnation groupings of matched live releases, plus a coverage note stating how many live releases could not be matched by date (box sets, compilations, undated titles) so the caller can decide to search further.
| Name | Required | Description | Default |
|---|---|---|---|
| song | Yes | ||
| match | No | exact | |
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It openly explains the matching mechanism (setlist cache + recording date parsed from title), limitations (excerpt compilations edge case), and the coverage note for unmatched releases, giving users an accurate expectation of behavior.
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?
Front-loaded with the main purpose, then organized into 'How it works,' prerequisites, Args list, and Returns. Each sentence adds essential information without redundancy, making it appropriately sized for the tool's complexity.
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?
Despite no output schema, the description explains the return value (by_incarnation groupings plus coverage note) and gives necessary context for decision-making. Prerequisites, edge cases, and parameter details are all covered, making the description complete for usage.
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 0% coverage, but description fully compensates by explaining every parameter: song with example, artist_mbid with default, match with allowed values and definitions. This adds complete meaning beyond the bare schema.
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?
First sentence states a specific action (Find official live releases) and a specific resource (captured a given song), plus grouping by incarnation. It clearly distinguishes from sibling tools like song_box_sets and song_performance_history.
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 clear context: requires both caches to be refreshed first, and explains the matching logic and edge cases. However, it does not explicitly name alternative tools for when-not-to-use, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace how often and when a song was played live, from the local setlist cache. Run refresh_setlist_cache first. Aggregates by year and by tour so a song's life across decades and line-ups is visible at a glance.
Args: song: Song title to trace (e.g. "Starless", "21st Century Schizoid Man"). artist_mbid: MusicBrainz artist MBID. Defaults to King Crimson. match: "exact" (case-insensitive full title) or "contains" (substring).
Returns: A dict with cache_info, performance_count, first/last performance, by_year and by_tour breakdowns, and the list of performances.
| Name | Required | Description | Default |
|---|---|---|---|
| song | Yes | ||
| match | No | exact | |
| artist_mbid | No | b38225b8-8e5f-42aa-bcdc-7bae5b5bdab3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the tool reads from a local cache and depends on freshness (refresh prerequisite). It also describes the return structure in detail. It implies a read-only operation but never explicitly states 'does not modify data', and it does not mention edge cases like cache emptiness. Still, it is reasonably transparent for a cache-backed lookup.
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 structured into a brief summary, an Args block, and a Returns block. It front-loads the purpose, includes necessary parameter details, and avoids redundancy. Each sentence adds value, and the format is easy to parse.
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 moderate complexity (3 params, no output schema, no annotations), the description is complete. It covers the tool's purpose, data source, prerequisite, all parameters, and the return dictionary contents (cache_info, performance_count, first/last, by_year, by_tour, list). This is everything an agent needs to invoke it correctly and interpret results.
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 schema has no parameter descriptions (0% coverage), but the description fully compensates: it explains 'song' with examples, notes the default for 'artist_mbid' (King Crimson), and defines the two allowed values for 'match' (exact vs contains). This gives the agent complete information to construct valid calls.
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 opens with a specific verb+resource: 'Trace how often and when a song was played live.' It further clarifies the data source (local setlist cache) and the aggregation by year and tour. This clearly distinguishes it from sibling tools like get_live_history which likely lack this song-specific aggregated view.
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 states a clear prerequisite: 'Run refresh_setlist_cache first.' It also specifies the context (local setlist cache) and gives an idea of when results will be useful. However, it does not explicitly compare to alternatives (e.g., get_live_history or song_live_releases), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0get_artworkget_creditsget_editionsget_incarnationsget_live_historyrefresh_box_sets_cacherefresh_live_releases_cacherefresh_setlist_cachesearch_releasesong_box_setssong_live_releasessong_performance_historyScored across 12 tools
Most tools target distinct resources (albums, credits, editions, artwork, setlists, incarnations, song analyses), and descriptions clearly delineate boundaries. The three refresh_* tools and three song_* tools are each distinct by domain, though get_live_history and song_performance_history both touch live performance data and could be briefly confused before reading details.
There are multiple naming conventions: get_* for direct lookups, search_release for searching, refresh_* for cache updates, and song_* for song-specific analyses (which drop the leading verb). While each family is internally consistent, the mix of verb-first and noun-first patterns across the tool set is noticeable and not fully uniform.
Twelve tools is well within the ideal range and each appears justified for the server's purpose of King Crimson discography and live-performance research. The count covers exploration, analysis, and necessary cache maintenance without feeling bloated or sparse.
The tool surface covers the core workflows: searching albums, retrieving credits, editions, artwork, live history, incarnations, and per-song analyses across live releases and box sets. Minor gaps exist—there's no direct song search tool, and the song analysis tools depend on running refresh_* commands first—but these are workable given clear prerequisites and the ability to discover songs via get_credits.
MCP server for Producer/Riffusion AI music generation
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
An MCP server that provides congressional transcripts
