Skip to main content
Glama
Sign In
lyricmood-mcp

lyricmood-mcp

by yigitates17
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Update Spotify Playlist

update_spotify_playlist

Modify your own Spotify playlist by removing, appending, or reordering tracks in one call; confirm with the user before changing their account.

Instructions

Change one of the user's own playlists: remove tracks, append tracks (ones already in it are skipped), and/or set a completely new order, in that sequence. This changes the user's account: confirm with the user first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "playlist_id": "<playlist_id>"
    },
    "name": "update_spotify_playlist"
  }
}

Input Schema

NameRequiredDescriptionDefault
addNoTracks to append. Spotify track IDs, URLs or URIs (use `id` from search_track or build_mood_playlist). Song names are not accepted here.
removeNoTracks to remove (every occurrence). Spotify track IDs, URLs or URIs (use `id` from search_track or build_mood_playlist). Song names are not accepted here.
reorderNoThe complete new order: every track ID the playlist will contain after add/remove, each exactly once. Get the current list from get_playlist_tracks.
playlist_idYesSpotify playlist ID, URL or URI (use `id` from get_my_playlists).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the internal operation order (remove, then append, then reorder), the dedupe rule ('ones already in it are skipped'), and the account-mutating, confirm-first nature of the call. It stops short of stating what is returned or whether a reorder is validated against the playlist's final contents, which would matter for a mutation with no output schema.

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, front-loaded with the operations and backed by the safety caveat, with zero filler. The parenthetical about skipped duplicates is compact and carries real behavioral information.

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 4-parameter destructive mutation with no annotations and no output schema, the description covers ordering, ownership, dedupe, and the need for confirmation. What remains unstated is the return value or any partial-failure behavior when one of several operations fails, which an agent would want before composing a multi-step edit.

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 four parameters and their ID/URI formats are already fully documented. The description's one genuine addition is the execution order 'in that sequence', which matters because reorder must reflect the post-add/remove state, but that nuance is already implied by the reorder field's own schema text. Baseline 3 fits since the schema does the heavy lifting.

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?

The description names a specific verb and resource ('Change one of the user's own playlists') and enumerates the three supported mutations (remove, append, reorder). The ownership qualifier 'user's own' plus the enumerated operations clearly separate it from create_spotify_playlist and the read-only playlist siblings.

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?

It gives a clear usage condition (editing an existing playlist owned by the user) and a strong guardrail ('confirm with the user first'), and the sequencing clause implies reorder should come last. However, it never explicitly names create_spotify_playlist as the alternative for new playlists or get_playlist_tracks as the prerequisite read step, both of which live only in the schema.

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