> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rewind.rest/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect via the hosted server

> Connect a mobile or web MCP client to the hosted Rewind server at mcp.rewind.rest, using either a Bearer token or the GitHub sign-in flow.

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](/mcp/connect-local) 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](/authentication) as a Bearer token.

```json title="remote-mcp-config.json" theme={null}
{
  "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](/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.

<Steps titleSize="h3">
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### 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.

<Note>
  See [troubleshooting](/troubleshooting#claude-and-mcp) for how to resolve a
  `403` and other connection errors.
</Note>

### Scopes

The authorize request can ask for a broad `read` scope or for individual per-domain read scopes. The server advertises the full set:

| Scope             | Grants read access to |
| ----------------- | --------------------- |
| `read`            | Every domain          |
| `read:listening`  | Listening data        |
| `read:running`    | Running data          |
| `read:watching`   | Watching data         |
| `read:collecting` | Collecting data       |
| `read:reading`    | Reading data          |
| `read:feed`       | The 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:

| Token         | Lifetime |
| ------------- | -------- |
| Access token  | 1 hour   |
| Refresh token | 90 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.