Skip to main content
Glama

Delete Playlist

delete_playlist
DestructiveIdempotent

Permanently delete one of your playlists. The videos in it are not affected.

Instructions

Permanently delete one of your playlists. The videos in it are not affected.

Without confirm, nothing is deleted and the error describes the playlist.

Quota: 52 units.

Input Schema

NameRequiredDescriptionDefault
confirmNoThe playlist ID again, passed only after the user has approved deleting this playlist.
playlistYesPlaylist ID or URL.
my_channelNoWhich of your logged-in channels to work on: UC… ID, @handle or exact title. Omit for the default channel.

Output Schema

NameRequiredDescriptionDefault
idYes
kindYes
already_goneNoNothing to delete: it didn't exist or was already deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.1
    • changedOutput schema / properties / kind / enum
      Previous value: -[
      -  "video",
      -  "playlist",
      -  "comment",
      -  "section"
      -]New value: +[
      +  "video",
      +  "playlist",
      +  "comment",
      +  "section",
      +  "caption"
      +]
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations (which already flag destructiveHint=true and idempotentHint=true) by spelling out permanence, that contained videos survive, the dry-run behavior when confirm is omitted, and a concrete quota cost of 52 units. This is exactly the operational context annotations cannot carry.

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 short paragraphs, front-loaded with the destructive action and its blast radius, then the confirm rule, then quota. No redundant restatement of the name or 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?

An output schema and full annotations exist, and the description still covers the destructive semantics, side-effect scope, confirm gate, and quota. Only minor gaps remain, such as ownership/permission requirements or behavior when the playlist is not yours.

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?

Schema coverage is 100%, so the baseline is 3; the description raises it by explaining the confirm protocol as a safety gate rather than just another field. It does not restate the playlist/my_channel formats, correctly leaving those to 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?

States a specific verb and resource ("Permanently delete one of your playlists") and immediately clarifies collateral scope ("The videos in it are not affected"). It does not explicitly name the nearby alternative remove_from_playlist, which shares the playlist domain, so an agent must infer the distinction from the verb alone.

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?

Explicitly documents the two-step gate: "Without confirm, nothing is deleted and the error describes the playlist," which tells the agent exactly how to preview before committing. It offers no guidance on when to choose this over remove_from_playlist or update_playlist, so exclusions are absent.

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