Skip to main content
Glama
chrischall

setlist-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

setlist_mark_attended

Idempotent

Record attendance for a concert on your setlist.fm account by setlist ID. Sets the 'I was there' marker and confirms it on your attended list.

Instructions

Record on YOUR setlist.fm account that you attended a show — the site's "I was there" marker — by setlist ID. Authenticated via your session (needs SETLIST_SESSION_COOKIE). Idempotent: a no-op if already marked. Reversible with setlist_unmark_attended. Toggles attendance and verifies by re-reading your attended list. 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
setlistIdYesSetlist ID (e.g. from setlist_search_setlists / resolve_concerts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.3
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to actually record attendance; omit for a dry-run preview.",
-  "type": "boolean"
-}
  2. 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"
  3. Addedv0.7.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond annotations, it discloses the auth requirement, the post-write verification step ('verifies by re-reading your attended list'), and the attribution/URL-citation requirement. However, the phrase 'Toggles attendance' is ambiguous—it seems to contradict the previously stated no-op idempotency, which could mislead an agent into thinking the tool flips the attendance state.

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

Conciseness4/5

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

The description is front-loaded with the core action and then covers auth, idempotency, reversibility, verification, and attribution. While every sentence adds value, it is somewhat lengthy for one parameter, with minor superfluous text like 'the site's "I was there" marker' and a long attribution policy. Still, it remains structured and efficient overall.

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

Completeness5/5

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

For a one-parameter tool with no output schema, the description is remarkably complete: it covers authentication, idempotency, the reversal path, verification behavior, and the expected url field with clear attribution instructions. An agent has enough information to invoke the tool correctly and handle the result.

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% and the single parameter setlistId is fully documented in the schema with a source hint. The description only repeats 'setlist ID' without adding extra meaning, so the schema carries the load; baseline 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 clearly states the action ('Record on YOUR setlist.fm account that you attended a show'), the specific resource (your attendance marker on setlist.fm), and the identifier (setlist ID). It explicitly references the sibling setlist_unmark_attended, making it easy to distinguish from related tools like setlist_get_user_attended.

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

Usage Guidelines5/5

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

It gives a concrete prerequisite ('needs SETLIST_SESSION_COOKIE'), states when it is safe to call even if already marked ('no-op if already marked'), and names the exact alternative for reversal ('Reversible with setlist_unmark_attended'). This provides explicit when, when-not, and alternative 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