Skip to main content
The hosted Rewind MCP server runs as a Cloudflare Worker at https://mcp.rewind.rest/mcp. Use it when your client cannot launch a local process: Claude on iOS, claude.ai, ChatGPT, and other clients that connect to a remote URL. If you are on a desktop that can run a child process, connect over local stdio instead. The MCP endpoint is always https://mcp.rewind.rest/mcp. How you authenticate depends on your client. Some clients let you paste a static Bearer token. Others speak full OAuth and walk you through a GitHub sign-in. Both paths reach the same server.

​
Connect with a Bearer token

If your client lets you add a remote MCP server with a custom authorization header, point it at the endpoint and pass your Rewind API key as a Bearer token.
remote-mcp-config.json
{
  "url": "https://mcp.rewind.rest/mcp",
  "headers": {
    "Authorization": "Bearer rw_live_..."
  }
}
Use a read key. The server only exposes read tools, so an admin key buys you nothing here. See authentication for how to mint a key.

​
Connect with GitHub sign-in

Clients that implement the full OAuth 2.1 handshake (claude.ai and Claude on iOS, for example) do not ask you for an API key. You add the server by URL, and the client redirects you through a consent flow. The Worker uses GitHub as the upstream identity provider and maps your GitHub account to a Rewind user behind the scenes.
1

Add the server by URL

In your client’s integrations or connectors settings, add a remote MCP server with the URL https://mcp.rewind.rest/mcp. Leave the authorization field blank if the client offers one; the OAuth flow supplies the token.
2

Approve the consent screen

The client opens the Rewind authorize page. It names the client requesting access and the scopes it is asking for. Review it, then choose to sign in with GitHub.
3

Authenticate with GitHub

GitHub prompts you to authorize the connection. After you approve, GitHub redirects back to the Worker, which looks up your GitHub account against the Rewind allowlist.
4

Land back in your client

On success the Worker issues an access token and refresh token to your client and redirects you back. The connection is now active and Rewind tools are available.

​
The allowlist

Rewind is a single-user personal archive, so the hosted server does not grant access to anyone with a GitHub account. The Worker keeps an allowlist that maps specific GitHub user IDs to Rewind users. If your GitHub account is not on it, the callback fails with a 403 and a message naming your GitHub login and ID, telling you to contact the Rewind admin to request access. To get added, send the admin the GitHub login and numeric user ID shown in that error.
See troubleshooting for how to resolve a 403 and other connection errors.

​
Scopes

The authorize request can ask for a broad read scope or for individual per-domain read scopes. The server advertises the full set:
ScopeGrants read access to
readEvery domain
read:listeningListening data
read:runningRunning data
read:watchingWatching data
read:collectingCollecting data
read:readingReading data
read:feedThe cross-domain feed
Every scope is read-only. The server exposes no write or admin tools regardless of which scopes a client requests.

​
Token lifetimes

Once authorized, your client holds two tokens and refreshes the short-lived one as needed:
TokenLifetime
Access token1 hour
Refresh token90 days
When the access token expires, the client exchanges the refresh token for a new one without prompting you. You re-run the GitHub sign-in only after the refresh token lapses or if access is revoked. The flow uses PKCE with S256 only. Plain PKCE is rejected, per the MCP specification, so a compliant client handles this automatically.

​
Rate limit

The hosted server caps requests at 120 per minute per client IP address. Exceed it and the server responds with 429 Too Many Requests and a Retry-After: 60 header. Back off for a minute and the window resets. Normal interactive use stays well under this ceiling; you mostly hit it with tight automated loops.