Available tools

The MCP server exposes 56 tools across 10 areas. Tools that read public catalog data work without authentication. Tools that touch a user’s library, upload media, or issue a licence need an authenticated caller.

Authenticated in the tables below means either path works — the OAuth browser flow from Quickstart, or a partner token sent server-to-server. There is no separate tool set for either: the same 56 tools are exposed both ways. What changes is how you authenticate and, for a partner, that usage is attributed per end user via X-User-ID. See Server-to-server.

Start here

Search and discovery

Filter values are matched against the catalog’s own labels case-insensitively, so hip-hop lands on Hip Hop. An unrecognized value is dropped rather than applied. If a filter stack matches nothing, the search retries once without filters and reports which constraints it dropped in relaxed_filters.

search_sfx reads a different catalog. Sound effects are not tracks: search_tracks never returns one, search_sfx never returns a track, and a sound effect has genre and duration only — no mood, tempo, vocals, or BPM. Its two genre fields are independent assignments, not a hierarchy, and both match exactly, so take the values from get_sfx_filters rather than passing a guess. The REST equivalent is Sound effects.

Tracks

The URL is an MCP-hosted alias (https://mcp.slipstreammusic.com/dl/<token>), not a raw S3 link. The bucket, key, and signature stay server-side, and the partner’s download quota is consumed when the link is opened — not when the tool is called.

User and library

Playlists

Playlist tools key on the slug, except like_playlist, unlike_playlist, and download_playlist, which take the playlist UUID (id). Both come back on every playlist result.

Editing: clips and extend

Two opposite workflows on the same track. Clip makes it shorter, extend makes it longer.

Soundtrack a video

Upload a video, get tracks that fit it, render the mix. The REST equivalent is documented in Soundtrack a video.

Only uploaded files can be rendered. A YouTube URL supports recommendations only. render_soundtrack is asynchronous — poll it with identical arguments until ready: true.

The flow, end to end. In a chat client the agent chains these for you. Calling the server directly, you make each call yourself:

1. prepare_video_upload(filename)          -> upload_url, storage_key
2. PUT the bytes to upload_url
3. register_video(storage_key)             -> soundtrack id
4. recommend_tracks(soundtrack_id)         -> ranked tracks
5. render_soundtrack(soundtrack_id, track_id)
   -> poll with identical arguments until ready: true

Step 3 also accepts a youtube_url instead of a storage_key, which skips steps 1–2 but rules out step 5.

AudioVerify

Identify the music used in a video and flag licensing risk. AudioVerify informs, it does not enforce. See the AudioVerify guide for the full flow and the REST equivalent.

A video can use several songs one after another, so the result is segments: every stretch of music in timeline order, each with its timerange, title, artist, isrc, score, cleared (true when the user’s subscription covers it) and external_label (the registered library, e.g. Epidemic Sound, when known). Report all of them, not just the first. track repeats the longest one for a single-line summary.

A segment with identified: false is music that could not be named — its other fields are null. Report it by its timerange and say it cannot be called cleared. When cleared is false, suggestions offers catalog tracks the user can actually use instead.

Empty segments on a completed job means no music was detected — a valid result, not an error. A status of error means the check itself failed.

The flow, end to end:

1. prepare_compliance_upload(filename)  -> upload_url, storage_key
2. PUT the bytes to upload_url
3. check_video_compliance(storage_key)  -> polls ~20s, returns status + segments
4. while status is "timeout":
   get_compliance_result(job_id)        -> keep waiting on the same job

Step 4 is the normal path, not an error branch: the tools return early on purpose so a host can’t cut the call off mid-wait, and a video carrying several songs takes a couple of minutes to finish.

start_video_compliance_check replaces steps 1–3 with a widget the user drops the file into — use it when you can’t upload the file yourself.

Channels and allowlist

Content ID can flag a creator’s own upload even when the Slipstream track in it is licensed. The allowlist is how that gets prevented: register the channel (or a single video) and claims stop firing on licensed use.

Channels

Supported providers: youtube (default), instagram, tiktok, facebook, website, rss.

Only YouTube needs a lookup. For every other provider, pass the profile handle or URL straight in as channel_id — an Instagram/TikTok/Facebook profile URL, a website, or an RSS feed URL.

The YouTube flow:

search_youtube_channels(query: "Acme Studios")
  -> { channels: [{ channel_id: "UCxxxx…", title: "Acme Studios", thumbnail_url: … }] }

add_channel(channel_id: "UCxxxx…", provider: "youtube")
  -> { success: true, channel: { id: "…", name: "Acme Studios", provider: "youtube" } }

Any other provider skips step one:

add_channel(channel_id: "https://instagram.com/acmestudios", provider: "instagram")

Adding a channel that is already on the user’s own allowlist returns success: true with already_added: true, since the desired end state holds. A channel registered to a different Slipstream account is a real rejection and surfaces as an error.

Individual videos

Like channels, re-adding a video already on the user’s own allowlist reports success: true with already_allowed: true.

Licensing

Turn a chosen track into a filled Slipstream licence, priced from the enterprise’s negotiated rate card. This is a different product from the partner Licensing API, which clears a track for an end user’s video.

The flow, end to end:

1. prepare_license(track_ids, …)  -> ready: false + `ask` (what's still missing)
   ask the user for what `ask` lists, then call again — repeat until ready: true
2. show the one-line `confirm` and get the user's yes
3. generate_license(same values)  -> contract_number, download_url

Step 1 is read-only and safe to call early with whatever you already know. Step 3 mints a contract number, so it runs once, after the user has approved the fee.

Pricing, media, and term are resolved server-side from the caller’s identity and rate card — they are never sent as inputs, so a caller cannot license against another enterprise’s card or name its own fee.

A usage that isn’t on the card returns a clear “needs a custom quote” message rather than a nearby price. Multiple track_ids produce one agreement listing them all in Schedule A, priced at the rate times the number of tracks.

Enterprises without a rate card on file get a message saying so instead of an error.

Which tools open a widget

To render these in your own product, see Rendering widgets. Call resources/list for the current set of widget URIs rather than hard-coding them.

Prompts

The server also registers six prompts — ready-made starting points a client can browse without knowing any tool names:

• Find music for a project
• Build a playlist from a creative brief
• Soundtrack my video
• Protect my channel from copyright claims
• License a track for a campaign
• Check a video for music rights issues

Notes

• Every tool is a thin wrapper around the Slipstream REST API. When the catalog improves, MCP gets the same improvement at the same time.
• Tool inputs and outputs are typed. Most clients show the full schema in their settings UI when you click a tool.
• Tools carry MCP behavior hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) so a host can, for example, confirm before a destructive call.
• Download and media links are opaque MCP-hosted aliases (/dl/…, /sv/…). The raw S3 URL never reaches the client.
• Partner caps. On a server-to-server token, limits and catalog entitlements apply at the partner level, not per X-User-ID. Downloads consume the partner’s quota when the link is opened, and render_soundtrack is metered by its own render cap. A call that exceeds a cap comes back with a clear message rather than a generic failure.