Skip to main content
Glama
Sign In
spotify-discovery-mcp

spotify-discovery-mcp

by wkbaran
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Finish a lane run

discovery_finish
Idempotent

Finalize a discovery lane by applying pick limits, adding your selected tracks to today's Spotify playlist, saving all state, and returning what was added.

Instructions

Step 4. Give your picks as refs (K, C or W), best first. The server applies the lane's limits (dropping from the end of your list), adds the tracks to today's playlist, saves all state, and returns what was added. Then reply with one line, "Done: " and the lane id: a separate job posts the report. Safe to repeat: a second call changes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lane": "<lane>"
    },
    "name": "discovery_finish"
  }
}

Input Schema

NameRequiredDescriptionDefault
whyNoOptional short reasons for K/C picks, quoted or attributed to a text source: {"K1": "Critical: 'acid-tipped breakbeats'"}. W picks already have theirs.
laneYesThe lane id from lanes.json, e.g. "a-dnb".
thinNoTrue if the research came back limited.
picksNoRefs, best first, e.g. ["W2", "K1", "W5"].
rejectNoAt most 3 refs that are clearly the wrong genre for this lane; they're never offered again. Don't list refs just because you didn't pick them: unpicked refs carry over by themselves.
dry_runNoShow the report without adding or saving anything.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations (which already flag mutation, idempotency, and non-destructiveness), it discloses the important hidden behavior: the server drops items from the end of the list to honor lane limits, appends to today's playlist, saves all state, and that reporting happens in a separate job. Those are real consequences an agent cannot infer from structured fields; only pagination/response shape detail is absent.

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 critical constraints, ordering, truncation, and idempotency are front-loaded and every clause carries information. It is dense but not padded; the embedded 'reply with one line' protocol is arguably agent-instruction rather than tool documentation, a minor structural blemish.

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

Completeness4/5

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

For a six-parameter mutating tool with no output schema, it covers the essentials: what is written, how limits are applied, what is returned ('returns what was added'), and that the human-facing report is produced elsewhere. Remaining gaps (response shape details, what 'thin' does downstream) are small given 100% schema coverage on the parameters.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: 'best first' ordering matters because truncation happens at the tail, and reject refs are 'never offered again' while unpicked refs 'carry over by themselves.' That carryover/decay rule is not derivable from the schema and directly shapes how an agent should fill the list.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Step 4' and states the specific action: submit picks as refs (K/C/W), which the server trims to lane limits, writes into today's playlist, and persists. That is a concrete verb-plus-resource story an agent can distinguish from discovery_begin/fill/review by the step label, though the sibling tools themselves are never named.

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?

'Step 4' plus the post-call protocol ('Then reply with one line, "Done: " and the lane id: a separate job posts the report') makes the position in the workflow and the hand-off clear. It also states 'Safe to repeat: a second call changes nothing,' which resolves the retry question. It stops short of explicitly saying when NOT to use it (e.g., call discovery_review first, or use dry_run to preview).

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