Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

reorder_playlist_items

Move a range of items to a new position in a Spotify playlist. Use dry_run to preview changes or specify range_start, range_length, and insert_before.

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).

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. 0-based index into the playlist's current item order (0 = the first item).
range_lengthNoNumber of items to move. Default: 1
insert_beforeYesIndex to insert the range before. 0-based index into the playlist's current item order (0 = the first item).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • changedInput schema / properties / insert_before / description
      Previous value: -"Index to insert the range before"New value: +"Index to insert the range before. 0-based index into the playlist's current item order (0 = the first item)."
    • changedInput schema / properties / range_start / description
      Previous value: -"Index of the first item to move"New value: +"Index of the first item to move. 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. 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
  4. First observedv1.0.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only supply destructiveHint=false, so the description carries the rest, and it earns its keep by disclosing the non-obvious Spotify index-shift semantics ('when insert_before > range_start, the effective destination shifts down by range_length'), with a concrete example. That is real behavioral context beyond the annotations, though it omits side effects like snapshot changes or auth requirements.

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 sentences, action front-loaded, followed by the one piece of tricky semantics and a compact illustrative example. No filler, no repetition of the schema.

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 no-output-schema mutation tool with full schema coverage and a destructiveHint=false annotation, the description supplies the key gotcha an agent needs to call it correctly (index shifting), plus the existence of a dry_run parameter is visible in the schema. Missing only peripheral details like confirmation/snapshot behavior.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains the conditional interaction between insert_before and range_start, clarifying what each index value actually does to the resulting order. This is parameter-level semantics beyond the field descriptions.

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 scoped to a single playlist ('Move a range of items within a playlist'), which implicitly separates it from cross-playlist siblings like move_items_between_playlists. It does not, however, name any sibling explicitly (e.g. playlist_sort, playlist_reverse), so an agent must infer the boundary itself.

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

Usage Guidelines3/5

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

Usage is only implied: the phrase 'within a playlist' hints at the in-playlist scope, but there is no explicit when-to-use, when-not-to-use, or named alternative such as playlist_sort or move_items_between_playlists. An agent gets the context but no routing guidance.

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