Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

backup_library

Read-onlyIdempotent

Export your entire Spotify library to a local JSON file, covering liked tracks, saved albums, shows, episodes, audiobooks, followed artists, and playlists.

Instructions

Snapshot your ENTIRE library to a local JSON file (read-only against Spotify): liked tracks, saved albums/shows/episodes/audiobooks, followed artists, and every playlist with its items. Walks capped at SPOTIFY_MCP_FETCH_ALL_CAP (500/category) and each playlist at SPOTIFY_MCP_PLAYLIST_ITEMS_CAP (500); the smaller wins, so a full backup of a large playlist needs both raised. Files land in SPOTIFY_MCP_BACKUP_DIR (default ~/.spotify-mcp/backups), mode 0600.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoFree-text note stored in the snapshot _meta block
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
walk_capNoCap on items per category walked for THIS call (default: SPOTIFY_MCP_FETCH_ALL_CAP). Bounds what is READ, not rows rendered — use max_results to shrink the response.
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • removedInput schema / properties / max_results
      Removed value: -{
-  "description": "Per-category walk cap for THIS call (default: SPOTIFY_MCP_FETCH_ALL_CAP)",
-  "exclusiveMinimum": 0,
-  "maximum": 2000,
-  "type": "integer"
-}
    • addedInput schema / properties / walk_cap
      Added value: +{
+  "description": "Cap on items per category walked for THIS call (default: SPOTIFY_MCP_FETCH_ALL_CAP). Bounds what is READ, not rows rendered — use max_results to shrink the response.",
+  "exclusiveMinimum": 0,
+  "maximum": 2000,
+  "type": "integer"
+}
  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

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds substantive context beyond that: read-only against Spotify, the two cap env vars and the 'smaller wins' interaction, the backup directory default, and file mode 0600. It does not describe failure modes or partial-write behavior, keeping it short of a 5.

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-loads the essential fact (full-library snapshot to local JSON) and then packs the operational caveats into compact clauses. Dense but every clause carries information; the long cap sentence is slightly heavy but justified.

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 usefully explains where files land, their mode, and the cap behavior, which covers what an agent needs to invoke and reason about the result. It stops short of describing the file's internal structure or how to locate a specific backup later.

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 all four parameters are already documented in the schema. The description reinforces the cap mechanics (walk_cap vs the env default, playlist cap interplay) but adds little that the schema does not already say. Baseline 3 is appropriate.

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 (snapshot) and resource (entire library) plus the destination (local JSON file), and enumerates the categories captured. It does not explicitly contrast itself with siblings like export_library_json, export_all_playlists, or backup_first, so an agent must infer the distinction from the 'ENTIRE library' scope.

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?

The description implies when it applies (full-library snapshot) and gives operational context about caps and env vars, but never says when to choose it over export_library_json, backup_first, or export_all_playlists, nor when-not to use it. Usage is inferred rather than directed.

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