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. For the normal save flow, use save_to_offstereo with the returned preview id; it saves privately to OffStereo and offers Continue to Apple Music on the website. Only for an explicitly requested direct music-service save after approval, previewOnly=false with the approved tracks and the same concise editorial name creates one private playlist in the listener's active music service. Apple Music is the public save destination; Spotify saving requires an explicitly enabled test deployment. Pass service only when the listener explicitly names a destination. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_playlist"
  }
}

Input Schema

Name	Required	Description
`name`	No	A concise editorial playlist title. Omit it when the listener did not supply a title; OffStereo derives one from the prompt.
`count`	No	Target song count for prompt-generated playlists (1-50, default 20).
`prompt`	No	A conceptual playlist request, e.g. 'connect A Tribe Called Quest to Steely Dan'.
`tracks`	No
`service`	No	Destination service. Pass only when the listener explicitly names one; otherwise OffStereo uses the active service on their account.
`previewOnly`	No	Resolve 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.
`pendingActionId`	No	Retry token returned by a prior auth_required result.
`requiredArtists`	No	Every artist the user explicitly requires, especially endpoints in a request such as 'from Minnie Riperton to Solange'. OffStereo validates these before creating anything.
`allowSecondPlaylist`	No	True 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

Name	Required	Description
`id`	No
`title`	No
`object`	Yes	Always 'playlist'.
`status`	Yes	preview, preview_partial, saved_offstereo, created, partial, auth_required, or failed.
`tracks`	No
`webUrl`	No
`actions`	No
`message`	No
`privacy`	No	Requested vs. confirmed privacy state.
`service`	No
`spotify`	No
`warnings`	No
`retryTool`	No
`appleMusic`	No
`authReason`	No
`connectUrl`	No	Sign-in URL when status is auth_required.
`unresolved`	No	Songs that could not be confidently matched.
`connections`	No
`pendingActionId`	No	Retry token for a safe re-call after sign-in.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

changedOutput schema / description

Previous value: -"A playlist result. status is preview (unsaved, hearable), created, partial, auth_required, or failed. Songs that could not be matched are reported in `unresolved` rather than substituted."New value: +"A playlist result. status is preview (unsaved, hearable), preview_partial, saved_offstereo (private library snapshot, no music-service write), created, partial, auth_required, or failed. Songs that could not be matched are reported in `unresolved` rather than substituted."

changedOutput schema / properties / service / enum

Previous value: -[
-  "spotify",
-  "apple_music"
-]New value: +[
+  "spotify",
+  "apple_music",
+  "offstereo"
+]

changedOutput schema / properties / status / description

Previous value: -"preview, created, partial, auth_required, or failed."New value: +"preview, preview_partial, saved_offstereo, created, partial, auth_required, or failed."

First observedSep 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnly=false, openWorld=true, destructive=false; the description goes far beyond that, disclosing that previewOnly needs no music-service connection, that the direct save creates a private playlist in the active service, that Apple Music is the public destination while Spotify requires an enabled test deployment, and that sign-in recovery preserves pendingActionId for safe retry.

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 core action and the once-per-turn rule, and nearly every sentence carries an operational constraint rather than filler. It is dense with long multi-clause sentences covering several flows, which slightly hurts scannability but not correctness.

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?

For a 9-parameter, branching tool with an output schema and an auth-retry path, the description covers the preview vs. save vs. direct-save branches, service scoping, required-artist validation, and sign-in recovery. Nothing an agent needs to call it correctly is missing.

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 already 89%, so most parameter meaning is structured. The description still adds behavioral meaning beyond the schema — previewOnly replaces the whole save/no-save flow, service is conditional on explicit listener naming, allowSecondPlaylist explicitly does not authorize a second call, and requiredArtists is validated before anything is created.

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?

Opens with a specific verb and resource ("Create one playlist") and names the two input modes (natural-language idea or explicit track list). It also explicitly routes the save case to the sibling save_to_offstereo, so an agent can distinguish the two tools without opening either schema.

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?

Gives explicit when/when-not conditions: exactly one call per listener turn with no corrective second call, previewOnly=true for hear-first flows, previewOnly=false only for an explicitly approved direct music-service save, and service passed only when the listener names it. It names the alternative tool (save_to_offstereo) for the normal save path.

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

All OffStereo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?