Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

add_to_playlist

Adds tracks or episodes to a Spotify playlist, up to 100 URIs per call, with optional position, duplicate checks, and dry-run preview.

Instructions

Add tracks or episodes to a playlist. Max 100 URIs per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urisYesTrack or episode URIs to add
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
positionNoInsert at this index; appends if omitted. 0-based index into the playlist's current item order (0 = the first item).
playlist_idYesPlaylist ID
check_duplicatesNoSkip URIs that are already in the playlist instead of appending them (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.1
    • changedInput schema / properties / position / description
      Previous value: -"Insert at index; appends if omitted"New value: +"Insert at this index; appends if omitted. 0-based index into the playlist's current item order (0 = the first item)."
  2. Changed2 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed4 schema fields changedv1.26.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / check_duplicates
      Added value: +{
+  "description": "Skip URIs that are already in the playlist instead of appending them (default: false)",
+  "type": "boolean"
+}
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Preview only: validate inputs and describe exactly what would change without performing it",
+  "type": "boolean"
+}
    • addedInput schema / properties / position / maximum
      Added value: +9007199254740991
  4. First observedv1.0.1

TDQS

B3.3/5.0
Behavior3/5

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

The only annotation is destructiveHint=false, so the safety profile is thin and the description carries most of the burden. It discloses the 100-URI ceiling, but says nothing about dedup defaults, ordering/position side effects on existing items, idempotency, or error behavior for invalid URIs. This is adequate but clearly short of full behavioral disclosure for a mutation tool.

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?

Two short sentences, the action front-loaded and the limit immediately after. Nothing wasted and nothing buried.

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?

With five parameters, no output schema, and a mutation that can exceed a single-call limit, the description is thin: it omits how to handle more than 100 URIs, whether duplicates are skipped by default, and which sibling to use for bulk work. It is minimally viable but leaves a routing gap against batch_add_to_playlist.

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 schema already documents dry_run, position, check_duplicates, and the uris cap, so the baseline of 3 applies. The description's only parameter-relevant statement (max 100 URIs) duplicates maxItems: 100 in the schema, adding no meaning beyond it.

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?

States a specific verb (add) and resource (playlist) plus the item types accepted (tracks or episodes). It does not distinguish itself from the sibling batch_add_to_playlist, which appears to serve the same purpose at a different scale, leaving the agent to guess which to call.

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

Usage Guidelines2/5

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as batch_add_to_playlist, add_to_queue, or replace_playlist_items. The only hint is the 100-URI cap, which implies a bulk boundary but doesn't state how to route around it.

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