MCP Authentication

The MCP server has a single authentication path: browser-based OAuth that signs you in as your Part3 user. There are no API keys, no client secrets, and no headers to paste. Any signed-in Part3 user can authorize their MCP client through a consent flow.

Access gate — Prime only

MCP access is currently limited to:

Project Primes — users who are Prime on at least one project, and
Super-duper-admins (SDAs).

Anyone else — org admins, non-Prime contacts, viewers — will see an explicit access-denied page on the consent screen and the OAuth flow will not complete. There is no API-key fallback.

Flow

Run the one-liner for your client (see setup for Claude Code, Claude Desktop, or Cursor). No header, no secret.

Your MCP client opens a browser to /oauth/login on the MCP server. Sign in with your Part3 email and password (Firebase auth).

/oauth/consent lists the access being requested and the account you're signing in as. Approve it to continue. If you're not a Prime or SDA, this page returns access-denied instead.

The MCP server mints an opaque access + refresh token pair and hands them to your client. Subsequent MCP calls auto-refresh the access token in the background — you only re-authenticate every ~90 days.

Token lifecycle

Access tokens last 24 hours. Opaque (not a JWT) — looked up by hash on every MCP request.
Refresh tokens last 90 days and rotate on every use (RFC 6749 BCP).
Reuse detection: if your client ever presents a refresh token that has already been rotated, the entire token family is revoked (OAuth 2.1 §6.1). This protects against stolen-token replay. If it happens to you, remove and re-add the MCP server to reauthenticate.

Internally, the MCP server exchanges your access token for a short-lived proxy-style JWT when calling the Part3 API. You never see this — it's an implementation detail of how MCP forwards tool calls downstream as your user.

How it works

MCP Client                MCP Server                   Part3 API
    |                         |                            |
    | (initial connect)       |                            |
    | Authorization request   |                            |
    |------------------------>|                            |
    |                         |                            |
    |   browser opens         |                            |
    |   /oauth/login          |                            |
    |   (Firebase sign-in)    |                            |
    |   /oauth/consent        |                            |
    |   (Prime gate check)    |                            |
    |                         |                            |
    | access + refresh token  |                            |
    |<------------------------|                            |
    |                         |                            |
    | MCP request             |                            |
    | Bearer access_token     |                            |
    |------------------------>|                            |
    |                         | proxy JWT                  |
    |                         | as web-app user            |
    |                         |--------------------------->|
    |                         |                            |
    |                         |       tool result          |
    |                         |<---------------------------|
    | tool result             |                            |
    |<------------------------|                            |

What tools you'll see

The MCP server enforces your normal Part3 permissions on every call — your role on each org and project decides what you can read or write, identical to the web app. There's no separate MCP permission bit; if you can see a project in the web app, you can use the project tools against it through MCP.