Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

reorder_playlist_items

Move a range of playlist items to a new position by specifying the start index, range length, and destination. Handles index shifts when moving items downward, making playlist reordering predictable.

Instructions

Move a range of items within a playlist. Spotify semantics: when insert_before > range_start, the effective destination shifts down by range_length because the moved range is lifted out first (e.g. moving [2] to insert_before=4 lands it AT index 3). Also covers: playlist_resequence (full resequence), playlist_move_block — See also: playlist_resequence, playlist_move_block.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
playlist_idYesPlaylist ID
range_startYesIndex of the first item to move
range_lengthNoNumber of items to move. Default: 1
insert_beforeYesIndex to insert the range before

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.26.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • 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 / insert_before / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / range_length / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / range_start / maximum
      Added value: +9007199254740991
  2. First observedv1.0.1

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose a genuinely non-obvious behavioral detail: effective destination shifts down by range_length when insert_before > range_start. It also references dry_run as a preview mechanism. However, it omits permission requirements, mutation side effects, and response/error behavior, which are meaningful gaps for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is tight and the offset semantics earn their place. However, the final clause is redundant and confusing: 'Also covers ... — See also: ...' repeats the same tool names and leaves ambiguity about whether this tool subsumes them or merely relates to them.

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?

For a mutation tool with no annotations, no output schema, and five parameters, the description covers the most important semantic trap but leaves gaps: it does not describe the return value, clarify when to use associated sibling tools, or state required permissions or failure behavior. It is adequate for a straightforward range move but not fully complete for confident selection among many playlist-mutation tools.

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. The description adds real value beyond the schema by explaining the interaction between range_start, range_length, and insert_before, including a concrete example such as moving [2] to insert_before=4 landing at index 3. This is exactly the kind of relationship the individual parameter descriptions do not convey.

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 a specific verb and resource: 'Move a range of items within a playlist.' It further sharpens meaning by explaining Spotify's insert_before offset semantics with an example. However, the trailing 'Also covers: playlist_resequence...' blurs scope instead of cleanly differentiating this tool from those siblings.

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 explicit when-to-use or when-not-to-use guidance is provided. While the description mentions playlist_resequence and playlist_move_block in a 'See also' list, it never states when an agent should choose those alternatives over this tool, nor does it define the boundaries between them.

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