Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

upload_playlist_cover

Upload a base64-encoded JPEG to replace a playlist's cover image. Requires the ugc-image-upload scope; without it Spotify rejects the upload.

Instructions

Replace a playlist's cover image with a base64-encoded JPEG. Requires the ugc-image-upload scope on the Spotify developer dashboard app (plus playlist-modify-public/private); without it Spotify rejects the upload with 403.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
jpeg_base64YesBase64-encoded JPEG file contents (max 256 KB decoded)
playlist_idYesPlaylist ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed2 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"
+}
  3. First observedv1.0.1

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the sparse annotations (destructiveHint=false), the description discloses the mutation semantics ('Replace' = overwriting the existing cover), the external authorization dependency (ugc-image-upload scope), and the concrete failure behavior (Spotify rejects with 403). No contradiction with annotations. It could add what a successful response looks like, but the replace semantics and failure mode are the important behavioral facts.

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, roughly 40 words, with the core action front-loaded and the scope prerequisite plus its consequence in the second sentence. Every clause earns its place; no repetition of schema content.

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 simple three-parameter mutation with full schema coverage and no output schema, the description covers the action, input format, prerequisites, and error behavior — enough for an agent to invoke it correctly and anticipate the main failure. Minor gap: it doesn't state what a successful call returns or whether the previous cover is permanently lost, but 'Replace' plus the dry_run parameter keeps this marginal.

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 baseline is 3; the schema already documents playlist_id, jpeg_base64 (with max 256 KB decoded), and dry_run. The description reinforces that the image must be base64-encoded JPEG but adds nothing about the parameters that the schema doesn't already say.

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?

Opens with a specific verb and resource — 'Replace a playlist's cover image' — and adds the required input format (base64-encoded JPEG). This sharply distinguishes it from sibling cover tools like get_playlist_cover, clone_playlist_cover, and compare_playlist_covers, which read, copy, or compare covers rather than write them.

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?

The description gives clear, actionable context: it names the required ugc-image-upload scope (plus playlist-modify-public/private) and predicts the exact failure mode (403) if the scope is missing, so an agent can verify prerequisites before calling. It does not explicitly name alternative tools or exclusion conditions, leaving when-versus-alternatives routing mostly implicit.

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