Skip to main content
Glama
chrischall

setlist-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

setlist_get_artist_setlists

Read-only

Retrieve an artist's setlists, newest first, using their MusicBrainz ID. Results include setlist.fm URLs for source attribution and support pagination.

Instructions

Get an artist's setlists (most recent first) by their MusicBrainz ID (mbid). Paginated via p. Results include a setlist.fm url; when you present this data, cite it as a clickable source link to setlist.fm (their API terms require followable attribution — no nofollow). If a result has no url, link to https://www.setlist.fm instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pNoResult page number (defaults to 1)
mbidYesArtist's MusicBrainz ID (mbid)
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Setlist.fm's payload untouched. No field projection: this server has no verified record of which Setlist.fm fields matter, and inventing one would risk dropping a field a caller needs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv0.11.1
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Setlist.fm's payload untouched. No field projection: this server has no verified record of which Setlist.fm fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. First observedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses useful behaviors: result ordering, pagination, the presence of a setlist.fm url, and a concrete attribution policy including a nofollow restriction and fallback URL. It does not describe response fields or error behavior, but the annotation already covers the read-only safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences deliver the core purpose, pagination behavior, and a required attribution rule with no filler. The most important information is front-loaded, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for invoking the endpoint correctly, but since there is no output schema, it does not document the setlist object shape beyond the presence of a url. An agent presenting setlist data might need details like date, venue, or set content, which are not covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents mbid, p, and view adequately. The description adds no new parameter-level semantics beyond reiterating that mbid is the lookup key and p controls pagination, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 an artist's setlists' by MusicBrainz ID, and specifies ordering (most recent first). This clearly distinguishes it from sibling tools like setlist_search_setlists and setlist_get_setlist, which answer different queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear that the tool applies when an artist's MusicBrainz ID is available, and it explains pagination via `p` for larger result sets. It does not explicitly contrast with search-based siblings or state when not to use this tool, so it falls just short of full exclusionary guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools