Skip to main content
Glama

OffStereo

Create a playlist

create_playlist

Create one playlist from a natural-language idea or explicit track list. Call exactly once per listener turn: do not inspect the result and make a corrective second call or stack another playlist card in the same response. previewOnly=true returns one authoritative playlist that can be heard before saving and needs no music-service connection. After explicit approval, previewOnly=false with the approved tracks and the same concise editorial name creates one private playlist in the listener's active music service. Pass service only when the listener explicitly names Spotify or Apple Music. requiredArtists carries every artist the listener named as required. allowSecondPlaylist is true only for an explicit request for a separate additional playlist. Sign-in recovery preserves the exact request and pendingActionId for a safe retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA concise editorial playlist title. Omit it when the listener did not supply a title; OffStereo derives one from the prompt.
countNoTarget song count for prompt-generated playlists (1-50, default 20).
promptNoA conceptual playlist request, e.g. 'connect A Tribe Called Quest to Steely Dan'.
tracksNo
serviceNoDestination service. Pass only when the listener explicitly names one; otherwise OffStereo uses the active service on their account.
previewOnlyNoResolve one unified playlist preview without saving or requiring a music-service connection. True when the listener asks to hear, inspect, or approve the songs before saving.
pendingActionIdNoRetry token returned by a prior auth_required result.
requiredArtistsNoEvery artist the user explicitly requires, especially endpoints in a request such as 'from Minnie Riperton to Solange'. OffStereo validates these before creating anything.
allowSecondPlaylistNoTrue only when the listener explicitly requests another separate playlist. Omit or pass false otherwise; this does not authorize a second create_playlist call in the same response.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
titleNo
objectYesAlways 'playlist'.
statusYespreview, created, partial, auth_required, or failed.
tracksNo
webUrlNo
actionsNo
messageNo
privacyNoRequested vs. confirmed privacy state.
serviceNo
spotifyNo
warningsNo
retryToolNo
appleMusicNo
authReasonNo
connectUrlNoSign-in URL when status is auth_required.
unresolvedNoSongs that could not be confidently matched.
connectionsNo
pendingActionIdNoRetry token for a safe re-call after sign-in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations already indicating readOnlyHint=false, the description adds critical behavioral context: the two-phase preview-then-save flow, the requirement for explicit approval, the sign-in recovery mechanism, and the exact-once constraint. This goes well beyond the annotations.

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?

The description is long but information-dense; it front-loads the core purpose and then packs behavioral rules. No filler. Slightly long, but each sentence adds operational guidance, so it earns its length.

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?

With an output schema present and 89% parameter coverage, the description fills the remaining gaps: the two-phase flow, approval requirement, retry semantics, and exact-once rule. For a 9-parameter tool with a complex lifecycle, this is comprehensive.

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

Parameters5/5

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

Schema coverage is 89%, but the description enriches the meaning of key parameters: it explains that requiredArtists carries every artist the user names, that allowSecondPlaylist is strictly gated on explicit request, and that service should only be set when the user names a provider. These are non-obvious semantics not fully captured by 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?

The description opens with a clear verb+resource statement ('Create one playlist') and immediately distinguishes two modes (natural-language idea vs explicit track list). It also clarifies the tool's scope versus siblings by specifying it's a single call per turn, which differentiates it from other tools that might add multiple items.

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

Usage Guidelines5/5

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

The description gives explicit usage rules: call exactly once, use previewOnly for preview, switch to previewOnly=false after explicit approval, pass service only when explicitly named, and allowSecondPlaylist only on explicit request. These are concrete when-to and when-not-to instructions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources