SpotifyMCP

overlap_playlists

Find tracks shared across Spotify playlists: report how many playlists each track appears in and list those meeting a minimum shared-playlist count, most-shared first.

Instructions

Find tracks shared across playlists: reports how many playlists each track appears in and lists tracks present in at least min_overlap playlists (default: all of them), most-shared first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Source page size, 1–100. Default: 100
`dry_run`	No	Preview only: validate inputs and describe exactly what would change without performing it
`scan_cap`	No	Maximum source rows to scan; bounded by SPOTIFY_MCP_FETCH_ALL_CAP
`playlists`	No	Canonical ordered playlists (2–10)
`max_results`	No	Max items to return (default: SPOTIFY_MCP_MAX_ITEMS env or 50)
`min_overlap`	No	Minimum number of playlists a track must appear in. Default: all playlists
`response_format`	No	'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API object	concise

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.0.1Oct 1, 2026

changedInput schema / properties / playlists / description

Previous value: -"Canonical ordered playlists (2–10), or provide the complete documented legacy alias accepted by this tool"New value: +"Canonical ordered playlists (2–10)"

Changed9 schema fields changedv1.31.0Sep 25, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / limit

Added value: +{
+  "description": "Source page size, 1–100. Default: 100",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / playlists / description

Previous value: -"Two or more playlists, as IDs or spotify:playlist: URIs"New value: +"Canonical ordered playlists (2–10), or provide the complete documented legacy alias accepted by this tool"

addedInput schema / properties / playlists / items / description

Added value: +"Playlist ID, spotify:playlist: URI, or Spotify playlist URL; use this reference in the canonical or documented legacy field"

addedInput schema / properties / playlists / items / minLength
```
Added value: +1
```
addedInput schema / properties / playlists / maxItems
```
Added value: +10
```

addedInput schema / properties / scan_cap

Added value: +{
+  "description": "Maximum source rows to scan; bounded by SPOTIFY_MCP_FETCH_ALL_CAP",
+  "maximum": 10000,
+  "minimum": 1,
+  "type": "integer"
+}

removedInput schema / required
```
Removed value: -[
-  "playlists"
-]
```

Addedv1.26.1Aug 29, 2026

TDQS

B3.4/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 description must carry the rest. It usefully discloses the default threshold semantics and result ordering, which annotations do not cover, but says nothing about the read-only nature, the scan_cap/SPOTIFY_MCP_FETCH_ALL_CAP bounding behavior, truncation, or how dry_run interacts — despite dry_run being a declared parameter.

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?

One sentence that front-loads the core operation (shared tracks), then the report contents, the threshold default, and the sort order — no filler and nothing buried.

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 7-parameter read tool with no output schema, the description adequately conveys the operation and the shape of the result (counts plus qualifying tracks, ordered). It falls short only on dry-run semantics and the scan-cap/truncation limits that an agent would want before invoking.

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 all seven parameters (limit, scan_cap, playlists, max_results, min_overlap, response_format, dry_run). The description adds only the min_overlap default and the ordering, which is baseline value when the schema does the heavy lifting.

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 and resource — finding tracks shared across playlists — and even describes the output (per-track playlist counts, tracks meeting the min_overlap threshold, sorted most-shared first). It is clear without opening the schema, though it does not name or contrast with near-neighbors like find_duplicate_tracks_across_playlists, playlist_union, or diff_playlists.

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?

The description explains what happens by default (min_overlap defaults to all playlists) but never says when to choose this over intersecting/unioning siblings or what prerequisites apply. No when-not guidance or alternative routing is present, leaving selection to inference.

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

Deploy Server

overlap_playlists

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools