Skip to main content
Glama

edit_draft

Apply ordered changes to a draft playlist—rename, move, assign, merge, or skip tracks—and refresh its page without writing anything to Spotify. All changes apply together or none do.

Instructions

Change a draft, then refresh its page. All the changes are applied in order, or none if one fails. Only the draft (and the organize progress it touches) changes; nothing is written to Spotify.

Args: draft: the draft ID ("d3"). changes: a list of operations, each with an "op": rename {group, to}; move {tracks, to, from_group?, create_if_missing?} between groups; assign {tracks, to} puts unmatched tracks in a group (saved as manual progress, like the original's "Save assignments"); drop_group {group} (its tracks stay in the pool, listed as left out); merge {groups, into?}; keep_visible {group, on?} (its tracks aren't marked done when written); skip_unmatched {} (marks the unmatched tracks without data as done, so they leave the pool); reopen {group} (a done group counts as not done). tracks picks tracks by artist, text (in the name), genre, genre_family, decade, year_from/to, popularity, track_ids, reason (unmatched only) or all=true. Group names accept a unique part.

Input Schema

NameRequiredDescriptionDefault
draftYes
changesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.1

TDQS

A4/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it states atomicity ("applied in order, or none if one fails") and blast radius ("Only the draft (and the organize progress it touches) changes; nothing is written to Spotify"). It stops short of describing the returned payload, error surface, or whether the refreshed page is returned, which keeps it below 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-loaded with the two facts that matter most (atomic application, no writes to Spotify) before the dense Args block. The op enumeration is long but every entry explains a distinct behavior; a few phrasings repeat (e.g. the group-name "unique part" note appears both in prose and schema).

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 tool whose real complexity lives in an eight-variant discriminated union, the description covers ordering, failure semantics, mutation scope and per-op meaning. The remaining gap is the response: with no output schema, an agent is not told what "refresh its page" returns or what an error looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema coverage is 0% (draft and changes are bare in the schema), so the description must compensate, and it does: it gives the draft ID shape ("d3") and spells out the full semantics of every change op including optional flags. It omits several TrackSelector fields that only the nested schema documents (album, added_from, playlists, duration, popularity), so it does not fully replace the schema.

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?

"Change a draft, then refresh its page" names a concrete verb and resource, and the op list (rename/move/assign/drop_group/merge/keep_visible/skip_unmatched/reopen) makes the tool's scope unmistakable. It does not name any sibling tool, so the agent must infer that show_draft is the read counterpart and group_tracks the creator.

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?

Each operation is annotated with the situation it serves (assign = the original's "Save assignments", drop_group = tracks stay in the pool, skip_unmatched = unmatched tracks leave the pool, reopen = a done group counts as not done), which is genuine when-to-use guidance. What is missing is any routing advice against siblings such as show_draft, group_tracks or organize_progress.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.