Skip to main content
Glama

playlist_collab_toggle

Toggle a Spotify playlist's public and collaborative flags, preventing invalid public + collaborative settings. Supports dry-run preview before applying changes.

Instructions

Toggle collaborative/public flags (guards public=true && collaborative=true 400). Quota: GET + PUT.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
publicNoTarget visibility: true makes the playlist public
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
playlist_idYesPlaylist ID, spotify:playlist: URI, or URL
collaborativeNoTarget collaborative state for the playlist

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / collaborative / description
      Added value: +"Target collaborative state for the playlist"
    • addedInput schema / properties / playlist_id / description
      Added value: +"Playlist ID, spotify:playlist: URI, or URL"
    • addedInput schema / properties / public / description
      Added value: +"Target visibility: true makes the playlist public"
  2. Addedv1.26.1

TDQS

B3.4/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false. The description adds valuable behavior: the public=true && collaborative=true 400 guard and the GET + PUT quota cost. It omits auth/permission requirements, but this is well beyond annotation coverage.

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?

Two terse fragments, front-loaded with the main action; no filler. The parenthetical guard and quota line are slightly cryptic but efficient.

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?

For a flag-toggle mutation with full schema coverage and minimal annotations, the description supplies the key validation guard and quota. It lacks any routing guidance versus update_playlist, leaving a gap for tool selection.

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 documents all four parameters including dry_run. The description mentions the flags but adds no syntax or format beyond the schema. Baseline 3.

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 states a specific verb ('Toggle') and resource ('collaborative/public flags'), making the action clear. It does not explicitly name or distinguish sibling tools like update_playlist, so a 4 rather than 5.

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

Usage Guidelines2/5

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

No when-to-use guidance, no alternatives, and no exclusions are provided. The guard describes a validation rule, not usage context.

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