Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

snapshot_playlist

Save a playlist's current track URIs and positions to a JSON file, using a timestamp or custom snapshot ID. For transactional snapshots with diff and bundle tooling, use take_playlist_snapshot instead.

Instructions

Snapshot a playlist's current URIs+positions+timestamp to a sidecar JSON file (legacy, simple path playlistId→file). For transactional local snapshots with plsnapi naming, diff, and bundle tooling, use take_playlist_snapshot instead. Also covers: playlist snapshot (legacy).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
playlist_idYesPlaylist ID
snapshot_idNoCustom snapshot ID (default: timestamp)
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 changedv1.28.0
    • addedInput schema / properties / response_format
      Added value: +{
+  "default": "concise",
+  "description": "'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API object",
+  "enum": [
+    "concise",
+    "detailed",
+    "json"
+  ],
+  "type": "string"
+}
  2. Addedv1.26.1

TDQS

A4.1/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 behavioral burden. It explains the primary effect—writing a sidecar JSON file with URI/position/timestamp data—and notes the legacy path convention. However, it does not disclose whether existing files are overwritten, what the return value contains, or whether the operation has side effects beyond writing the file.

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 with no filler. The core behavior is front-loaded, the legacy caveat is immediately useful, and the sibling alternative is named without extra words.

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?

The definition is adequate for recognizing the tool and choosing it over the sibling, but without annotations or an output schema it should say more about return behavior and the file-writing side effect. The simple nature of the tool keeps this from being a lower score, but some operational details remain unspecified.

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 parameters. The description adds the notion of a timestamp and the simple playlistId-to-file mapping, but it does not materially deepen the meaning of snapshot_id or response_format beyond what the schema says.

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?

The description states a specific verb and resource: it snapshots a playlist's current URIs, positions, and timestamp to a sidecar JSON file. It also distinguishes itself from the sibling take_playlist_snapshot by naming it as the non-legacy transactional alternative.

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

Usage Guidelines5/5

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

Explicitly tells the agent when to prefer the sibling: 'For transactional local snapshots with plsnapi naming, diff, and bundle tooling, use take_playlist_snapshot instead.' This is a clear routing instruction, and the 'legacy, simple path' phrasing identifies the niche for this tool.

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