# How it works

> Revo validates who you are, works out what you're allowed to do from its own records, and shows your assistant only the tools that survive that check.

Product: Revo MCP Server. Source: https://www.revo.ai/docs/mcp/how-it-works

### Signing in

Revo's MCP server issues no credentials of its own. Sign-in is handled by **WorkOS AuthKit** at `sso.revo.ai`, the same identity service behind the Revo app. The server's only job is to check the resulting token and decide what it permits.

The whole exchange is automatic, and it's why you never paste a key:

1. **Your client asks the server who it answers to** It fetches `/.well-known/oauth-protected-resource` and learns the sign-in service is `sso.revo.ai`. This is the standard discovery document defined by RFC 9728.
2. **Your client registers itself** Dynamic Client Registration means the client obtains its own identity on the fly. Nothing is shared between users, and nothing was pre-provisioned by an administrator.
3. **You sign in and consent, in a real browser** Standard authorization code flow with PKCE (S256 required). Your password is entered on Revo's own sign-in page and is never seen by the AI client.
4. **The client receives a short-lived access token** Bound by audience to `https://api.revo.ai/mcp`, so it is useless anywhere else, including against Revo's other APIs. A refresh token keeps the connection alive without asking you again.
5. **Every subsequent request carries that token** And every one of them is re-validated from scratch. See below.

### What happens on each request

There is no trusted session sitting in memory. Each call your assistant makes runs the full check:

| Step | What is checked |
| --- | --- |
| **Validate the token** | RS256 signature against Revo's published JWKS keys, plus issuer, audience and expiry, with 30 seconds of clock tolerance. Anything wrong returns `401` with a pointer back to the discovery document, so the client knows to re-authenticate rather than guess. |
| **Resolve who you are** | The token carries an opaque user identifier and nothing else: no email, no role, no permissions. Revo maps it to a user record in its own database. |
| **Confirm you still belong** | Your active membership of your current workspace is re-checked. Removed from the workspace? The very next call fails, whether or not your token has expired. |
| **Compute your permissions** | From your workspace role in Revo's database, never from anything the token claims. |
| **Filter the tool list** | Tools whose required permission you don't hold are removed before your assistant ever sees them. |

Because this runs per request rather than per session, a role change or an offboarding takes effect immediately. There is no stale session to wait out.

### Permissions, concretely

Every tool declares one required permission, written `domain:action`. Your workspace role grants a set of them, cumulatively: an Admin holds everything a Member holds, plus more.

| Role | Permissions granted |
| --- | --- |
| **Member** | `meetings:read` `revo:ask` `action_items:read` `action_items:write` `memories:read` `memories:write` `documents:write` `brain:read` `brain:write` `usage:read` `workspaces:read` `workspaces:write` |
| **Admin** | All of the above, plus `usage:read_members`, the per-teammate usage breakdown. |
| **Revo staff** | Additionally the `revo_admin:*` set, and only while a feature flag names their email address. |

The check **fails closed** by design. A tool with no declared permission is never exposed to anyone; a request with no resolvable user gets an empty tool list rather than a default one. Adding a tool without also granting its permission makes it invisible, not accidentally public.

### Where the server runs

Revo's MCP server runs inside the main Revo API, behind the same TLS termination, edge protection and infrastructure as the product. It runs *stateless*: no conversation state is retained between calls, requests can be served by any instance, and session identifiers handed back to clients are encrypted rather than guessable. That is what makes the per-request revalidation above possible, and it means a deploy or restart never silently downgrades a live connection.