Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

find_duplicates_in_playlist

Read-onlyIdempotent

Find duplicate tracks in a Spotify playlist by URI, title+artist, or title, and return grouped matches with the rule applied.

Instructions

Find duplicate tracks in a playlist under one published matching rule. match_by selects the rule (uri — the same track object twice; name_artist — same name and credited artists, catching relinks and remasters; name — same title only) and the rule is echoed back as match_by, so a group count is never unattributable. See the duplicate-matching vocabulary in SPEC section 4.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
match_byNoWhich rule decides that two items are the same: `uri` (exact URI, the default), `name_artist` (case-insensitive name + credited artists, catches relinks/remasters), or `name` (case-insensitive name only). The rule applied is echoed in the result as `match_by`.
max_resultsNoMax items to return (default: SPOTIFY_MCP_MAX_ITEMS env or 50)
playlist_idYesPlaylist ID
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.1
    • addedInput schema / properties / match_by
      Added value: +{
+  "description": "Which rule decides that two items are the same: `uri` (exact URI, the default), `name_artist` (case-insensitive name + credited artists, catches relinks/remasters), or `name` (case-insensitive name only). The rule applied is echoed in the result as `match_by`.",
+  "enum": [
+    "uri",
+    "name_artist",
+    "name"
+  ],
+  "type": "string"
+}
  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. Addedv1.26.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that the applied rule is echoed back as `match_by` so a group count is never unattributable, plus a pointer to SPEC section 4 vocabulary — useful context beyond the annotations, though nothing about result shape or limits.

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?

Front-loaded with purpose, then rules; two sentences carry real information. The echo-of-`match_by` point is stated twice (once in prose, once in the schema description), a small redundancy that keeps it from being maximally tight.

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?

With no output schema, the description does supply the key return-context detail (rule echoed in the result) and the matching-rule semantics. It omits result shape beyond group counts and limit behavior, but is otherwise sufficient for calling the tool correctly.

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 coverage is 100%, so the schema already documents all four parameters including the enum semantics and the default. The description largely restates the `match_by` rules and its echo behavior, adding marginal value over the structured field, which is the expected baseline when the schema does the work.

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?

Specific verb (find) plus resource (duplicate tracks) and an explicit scope ('in a playlist'), which separates it from siblings like find_duplicate_tracks_across_playlists and remove_duplicate_playlist_items. An agent can classify it without opening the schema.

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?

It clearly explains which matching rule each `match_by` value selects and the real-world cases they catch (relinks, remasters), which is genuine usage guidance. It does not, however, explicitly route the agent away from the removal/clone siblings, so it stops short of the top mark.

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