MCPServer-to-server

Server-to-server

Most clients connect to the MCP server through the OAuth browser flow described in the Quickstart. That flow assumes a person is present to sign in.

If your backend calls the MCP server directly, on behalf of your own users, there is no browser in the loop. This page covers that case: authenticate with a token, and identify each end user with a header.

Server-to-server access is provisioned per partner. Contact the Slipstream team to get a token before you start.

Server URL

https://mcp.slipstreammusic.com/mcp

Authenticate with a token

Send the token issued to you as a bearer token on every request:

Authorization: Bearer <YOUR_TOKEN>

The MCP endpoint validates the token and runs the call. No browser, no OAuth round trip.

⚠️

Send the token on the very first request. MCP clients that discover auth on their own will start the browser OAuth flow when they get a 401. Supplying the token up front keeps the connection fully server-to-server.

Identify your users

Tell us which of your end users a call is for by adding an X-User-ID header:

X-User-ID: <YOUR_USER_ID>

X-User-ID is an opaque string that you choose, for example your own user id. We use it for attribution, deduplication, and usage reporting, so each call is tied back to the right end user. It is not a Slipstream account, and you do not need to create one per user.

This is the same convention used by the REST license endpoint.

Example request

A tool call carries both headers:

POST /mcp HTTP/1.1
Host: mcp.slipstreammusic.com
Authorization: Bearer <YOUR_TOKEN>
X-User-ID: user-12345
Content-Type: application/json
 
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_tracks",
    "arguments": { "query": "upbeat indie pop for a sneaker ad" }
  }
}

Notes and limits

  • The X-User-ID value is trusted because your token already authenticates you. Send accurate ids.
  • Usage limits and catalog entitlements apply at the partner level, not per X-User-ID. The header attributes activity to a user, it does not grant per-user limits or per-user access.
  • Reuse the same X-User-ID for the same end user across calls so attribution and deduplication stay consistent.

When to use REST instead

If your backend is calling operations programmatically and you don’t need an agent reasoning over the catalog, the REST API is usually simpler than speaking the MCP protocol. It uses the same Authorization: Bearer and X-User-ID headers.

QuickstartAvailable tools