Spotify MCP Server

Overview Schema Source Related Servers Discussions Admin

Add Tracks to Playlist

add_tracks_to_playlist

Add tracks or podcast episodes to a Spotify playlist by specifying the playlist ID and up to 100 track or episode URIs/URLs.

Instructions

Add tracks or podcast episodes to a playlist.

Args:
    playlist_id: Playlist ID
    track_uris: Track or episode URIs/URLs (up to 100). Bare IDs are tracks;
        pass spotify:episode: URIs or episode URLs for episodes.

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": {
      "playlist_id": "<playlist_id>",
      "track_uris": "<track_uris>"
    },
    "name": "add_tracks_to_playlist"
  }
}

Input Schema

Name	Required	Description	Default
`track_uris`	Yes
`playlist_id`	Yes

Output Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`snapshot_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.1Jun 2, 2026

removedOutput schema / additionalProperties

Removed value: -{
-  "type": "string"
-}

addedOutput schema / description

Added value: +"Result of a state-changing operation."

addedOutput schema / properties

Added value: +{
+  "message": {
+    "title": "Message",
+    "type": "string"
+  },
+  "snapshot_id": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Snapshot Id"
+  },
+  "status": {
+    "title": "Status",
+    "type": "string"
+  }
+}

addedOutput schema / required

Added value: +[
+  "status",
+  "message"
+]

changedOutput schema / title

Previous value: -"add_tracks_to_playlistDictOutput"New value: +"ActionResult"

Changed4 schema fields changedv1.0.0Jan 2, 2026

addedOutput schema / additionalProperties
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": {
-      "type": "string"
-    },
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"add_tracks_to_playlistOutput"New value: +"add_tracks_to_playlistDictOutput"

First observedAug 18, 2025

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety bar is low. The description adds one useful behavioral fact – a hard cap of 100 items per call – but says nothing about append position, duplicate handling, or how the playlist must be accessible to the caller.

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?

One-line purpose statement front-loaded, followed by a compact Args block with no filler. The size is appropriate for a two-parameter tool; only the redundant 'Playlist ID' restatement wastes a line.

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 an output schema present, return values needn't be explained, and the URI/episode semantics are covered. However, an agent still has to guess about append ordering, duplicates, and playlist editability, which matters for a non-idempotent write.

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 0%, so the description must carry the load; it explains that track_uris accepts bare track IDs, spotify:episode: URIs, or episode URLs, which is meaningful format guidance. playlist_id is only restated ('Playlist ID') with no format or ownership detail, leaving half the contract thin.

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 uses a specific verb+resource ('Add tracks or podcast episodes to a playlist') and clarifies that episodes, not just tracks, can be added. It doesn't differentiate itself from close siblings like add_to_queue, save_tracks, or remove_tracks_from_playlist, so it falls short of a 5.

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?

There is no explicit when-to-use guidance: nothing says to prefer this over add_to_queue, reorder_playlist, or save_tracks, nor any prerequisite such as needing to own or collaborate on the playlist. The only usable routing hint is the episode-vs-track URI convention, which is parameter-level rather than usage-level.

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

Deploy Server