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

# MCP Authentication

> How the MCP server authenticates you, what the consent screen controls, and where your tokens live.

The MCP server implements **OAuth 2.1** against the MCP authorization spec (revision `2025-06-18`). You do not need to understand any of it to connect — this page is for people who want to know what is happening, or who are debugging.

## What your AI client does

Nothing needs configuring because the server publishes its own metadata:

| Document                                 | Path                                      |
| ---------------------------------------- | ----------------------------------------- |
| Protected-resource metadata (RFC 9728)   | `/.well-known/oauth-protected-resource`   |
| Authorization-server metadata (RFC 8414) | `/.well-known/oauth-authorization-server` |
| Dynamic client registration (RFC 7591)   | `POST /register`                          |

The client discovers those, registers itself, and runs a normal authorization-code flow with PKCE. That is why the only thing you paste in is the server URL.

## Where the tokens live

<Note>
  Your Daysync credentials never reach your AI client.
</Note>

Your AI client holds a token for **the MCP server only**. The MCP server holds your Daysync tokens server-side, encrypted at rest, and refreshes them silently as they expire. The partner credential that identifies the application to the Integration API is also server-side and never leaves it.

So a compromised AI client exposes a revocable MCP session — not your Daysync account.

## Why it asks you to sign in every time

Connecting always forces a fresh sign-in, even if your browser already has a Daysync session.

This is deliberate. The sign-in used for connecting is a **separate session from app.daysync.com** — different domain, no shared sign-on. Reusing whatever session happened to exist meant a connection could silently bind to an account you were not expecting, and then stay on it for weeks. Forcing the sign-in makes the bound account explicit at the moment you choose it.

If you have several Daysync accounts, this is the moment to pick the right one. The consent screen also has a **Switch account** link.

## What the consent screen controls

The scopes you approve decide **which tools your client can see**. Approve only Tours · Read and you get the tour reading tools and nothing else.

It is worth being precise about what consent is and is not:

* Consent decides **tool visibility**.
* The partner credential's scopes and **your own Daysync role** decide what actually succeeds.

So consenting to a scope the application does not hold grants nothing — the call is rejected at the API with `403 INSUFFICIENT_SCOPE`. And consenting to a write scope does not let you edit a tour you are only a viewer on.

The scope list on the consent screen is generated from the application's real grant, so it should never offer you something that could not work.

## Sessions and expiry

|                   |                                      |
| ----------------- | ------------------------------------ |
| MCP access token  | 1 hour                               |
| MCP refresh token | 30 days                              |
| Daysync tokens    | Refreshed silently behind the scenes |

In normal use a connection lasts until you revoke it. If refresh fails, your client will prompt you to sign in again — that is the expected recovery path, not an error.

## Checking and ending a connection

Two tools are always available, on any connection:

| Tool         | What it does                                                           |
| ------------ | ---------------------------------------------------------------------- |
| `whoami`     | Shows the email, name, and account ID this connection is bound to.     |
| `disconnect` | Revokes **this** connection. The next request prompts a fresh sign-in. |

From the Daysync side, **Settings → Integrations** in the web app lists and revokes the connections belonging to your account.

<Note>
  Settings → Integrations only shows connections bound to **your** account. If a connection was bound to a different account it will not appear there — use the in-client `disconnect` tool instead, then reconnect with the right account.
</Note>

***

See also: [Scopes & Permissions](/scopes) for the full scope list, and [Troubleshooting](/mcp/troubleshooting).