Skip to main content
Glama

remove_from_library_by_playlist

Destructive

Remove tracks from Liked Songs if they also exist in a specified playlist. Preview changes by default; set dry_run=false to commit.

Instructions

Remove from Liked Songs any tracks that also appear in a given playlist. Quota: 2 GETs + DELETE (chunked). PREVIEWS BY DEFAULT — pass dry_run=false to commit. Removing 10+ saved tracks additionally requires elicitation confirmation (or SPOTIFY_MCP_CONFIRM=never for automation).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoPreview only: perform the read side and return a PLAN without changing anything. Default true — pass dry_run=false to commit.
playlist_idYesPlaylist ID whose tracks will be removed from library
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
    • addedInput schema / properties / dry_run / default
      Added value: +true
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only: validate inputs and describe exactly what would change without performing it"New value: +"Preview only: perform the read side and return a PLAN without changing anything. Default true — pass dry_run=false to commit."
  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

A4.5/5.0
Behavior5/5

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

Excellent beyond annotations: quota (2 GETs + DELETE, chunked), safe-preview default, the explicit commit switch, and the elicitation/SPOTIFY_MCP_CONFIRM=never override. Annotations only note destructiveHint=true; the description carries everything else an agent needs to know before mutating.

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?

Three dense sentences covering purpose, quota, safety default, and confirmation gate – front-loaded and free of padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a destructive mutation with no output schema, the description supplies the operational facts (cost, default, confirmation) that would otherwise be missing; nothing material is left 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 coverage is 100%, so dry_run, playlist_id and response_format are already fully documented in the schema. The description reinforces the dry_run default/commit behavior but adds no syntax or format detail beyond the schema.

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?

States a specific verb (remove), resource (Liked Songs), and scope (tracks that also appear in a given playlist), which cleanly distinguishes it from siblings like remove_from_library and remove_from_playlist.

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 preview-by-default and the conditions that trigger elicitation (10+ tracks) are explicit, and the dry_run commit path is named. It does not, however, route the agent to a sibling alternative for related operations.

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