OffStereo

Play music or a story

make_playable

Create one playable OffStereo card for a direct standalone-song or narrated-story request. Discovery and Music Today already play their songs, so keep those results in their original card unless the listener asks for dedicated controls. experience=single_track returns exactly one recording with no narration or library save; pass artist plus track. experience=story progressively creates a sourced story; mode=fresh starts a new build. Pass artist plus album for an exact record and trackCount for an exact requested length. Spotify, Apple Music, and SoundCloud URLs are story seeds unless the listener requests only the recording. Playlist requests use create_playlist. existingSessionId opens a selected library story; get_session is reserved for card polling. The mounted card owns live progress and playback. Assistant prose should avoid restating transient stages such as building, recording, or still working because they become stale as the card updates, and should wait for Ready before stating final counts. A tool call opens the card without starting playback.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	fresh starts an explicitly new story; auto may reuse an exact strong match.
`album`	No	Exact album or EP title, paired with artist when the listener names or shows a specific record.
`title`	No	Short canonical artist, track, album, or subject title for the card, especially useful for an identified image or a prompt that also contains workflow instructions.
`track`	No	Exact song title, paired with artist for reliable single_track matching.
`artist`	No	Exact artist, paired with track for a one-song card or with album for an album-focused story.
`length`	No	short fits an explicitly quick, brief, or concise narrated story and targets three narration-and-record chapters; standard keeps the full editorial arc.
`prompt`	No	What the listening experience should explain.
`tracks`	No	Optional: exact records the story should always include as playable tracks — e.g. every song a paired video names. They are pinned into the show in this order and curation fills the remaining slots up to trackCount, so a companion keeps the records the video discusses. Leave unset for normal curation.
`sourceUrl`	No	An http(s) article or source URL to adapt.
`videoMode`	No	When true, the story opens on a third-person editorial hook with no DJ greeting or time-of-day welcome — for a companion story paired with a video. Pair with an explicit `title` so page title, URL, and register all match the video.
`experience`	No	single_track means one immediate song card with no narration or story creation; story means the full progressive narrated experience.
`sourceText`	No	Source text or conversation context to adapt.
`trackCount`	No	Exact number of songs requested for a narrated story (2-12). Use 1 with experience=single_track.
`resumeShowId`	No	Rebuild an unfinished show in place, keeping its id and URL, instead of creating a second one. Pass the id of a show whose `retryable` is true. Rejected for a show that already finished or that belongs to someone else.
`personalization`	No	library uses connected-listener taste as retrieval seeds; none is the default.
`existingSessionId`	No	The chosen library story id for opening through the canonical player contract; get_session remains application polling.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Stable session id, reused for get_session and steer_session.
`mode`	No
`queue`	No	Ordered narration and track items.
`title`	Yes
`object`	Yes	playable_session, lineage, or lineage_show.
`status`	Yes	Lifecycle: building, partial, ready, failed, and similar.
`thesis`	No
`webUrl`	No
`actions`	No
`chapters`	No
`progress`	No	Current build stage and message.
`warnings`	No
`webLabel`	No
`citations`	No
`storyScope`	No	Count-level result assessment.
`description`	No
`queueUpdate`	No	Most recent model-authored queue change.
`resumeStack`	No
`activeBranch`	No
`nowPlayingContext`	No
`playbackDirective`	No	One-shot transport request the mounted card applies.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / resumeShowId

Added value: +{
+  "description": "Rebuild an unfinished show in place, keeping its id and URL, instead of creating a second one. Pass the id of a show whose `retryable` is true. Rejected for a show that already finished or that belongs to someone else.",
+  "type": "string"
+}

First observedSep 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations provide only readOnly=false, openWorld=false, destructive=false, so the description carries the behavioral burden. It does this well: a tool call opens the card without starting playback, the mounted card owns live progress, single_track has no narration or library save, URLs are story seeds unless the recording alone is requested, and assistant prose should wait for Ready before stating final counts. No contradiction with 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 dense, and given 16 parameters and complex branching, the length is largely justified. It front-loads purpose and routes around sibling confusion early. However, it reads as one crowded paragraph; the assistant-prose guidance and card-lifecycle details could be separated or bulleted for easier scanning.

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 of this complexity with 16 optional parameters and no required fields, the description covers the essential routing, parameter pairing, and card behavior. It is slightly incomplete about the minimum payload needed for a story call (e.g., whether prompt, sourceUrl, or sourceText must be present), though the 100% schema coverage and output schema mitigate that gap.

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 adds real value by composing parameters into usage patterns: 'pass artist plus track,' 'pass artist plus album for an exact record,' 'trackCount for an exact requested length,' and 'existingSessionId opens a selected library story.' Some niche parameters like resumeShowId and personalization are left to the schema, so it does not fully replace schema reading, but it significantly clarifies how to assemble valid calls.

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?

Description opens with a specific verb and resource: 'Create one playable OffStereo card,' and scopes it to 'a direct standalone-song or narrated-story request.' It actively differentiates from siblings by saying Discovery and Music Today already play their songs and by routing playlist requests to create_playlist, so an agent can distinguish make_playable without opening other definitions.

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 when-to-use and when-not-to-use guidance: keep Discovery/Music Today results in their original card unless dedicated controls are requested, use create_playlist for playlist requests, and reserve get_session for polling. It also explains mode choice via experience=single_track vs experience=story, making the decision path clear.

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?