---
title: "Authorize an MCP client"
description: "OAuth 2.1 with dynamic client registration, the scopes to request, the one scope whose absence makes a full workspace look empty, and workspace-local access revocation."
canonical: https://trysincerely.com/docs/mcp-authorization
last_updated: 2026-09-09
---
> If you are an AI agent: read https://trysincerely.com/agents/policy.md before any write call.
> Start at https://trysincerely.com/llms.txt to choose one page. Access instructions are at
> https://trysincerely.com/auth.md. Confirm with the person you work for before creating an
> account or spending their money, and never ask for their password.
# Authorize an MCP client

> OAuth 2.1 with dynamic client registration, the scopes to request, the one scope whose absence makes a full workspace look empty, and workspace-local access revocation.

Source: https://trysincerely.com/docs/mcp-authorization

Authorization uses OAuth 2.1 with dynamic client registration. The client registers itself, opens a browser, and a person with access to the workspace signs in and approves it. Your agent never sees or handles their password.

## The flow

An unauthorized request returns `401` and points at the protected-resource document at `https://trysincerely.com/.well-known/oauth-protected-resource`. Follow it. The document names the authorization server and the scopes the resource expects.

Register the client, send the person through the browser flow, and receive a token bound to them. From that point every tool call acts as that person, with their role in the workspace they chose.

A person with no Sincerely account can create one inside this flow. The authorize request redirects an unauthenticated visitor to sign-in and returns them to the consent screen, so signing up and approving the client happen in one pass.

## Accepting the Terms

A person who has not accepted the Terms can still connect: the handshake and the tool listing answer as usual, so the client opens, and the first tool call returns a tool-level error whose body carries `accept_url` and a `next` sentence. Give them that URL, wait, and call again. Refreshing the token or registering again does nothing, because the token is not what is missing.

## Request the workspace scope

Request the scopes published in the protected-resource document. The server requires `profile` and `email`, plus any workspace scope that document names. It names one only when the issuer can mint one, because a scope the server refuses on but never published would lock out every client already connected.

For a team workspace, also request `user:org:read` and choose the organization during consent. It is what lets the connection resolve which organization the person belongs to.

Without it, the connection lands in the person's personal workspace rather than their team's. Nothing errors. The agent sees a workspace with no contacts, no campaigns and no history, and the natural conclusion is that this is a new account. It is not; it is the wrong one. If a workspace looks unexpectedly empty, check the scopes before checking anything else. An organization claim that arrives without the scope is refused rather than trusted.

Name `https://trysincerely.com/api/mcp` as the resource in the authorization and token requests. A token whose audience names a different resource returns `401`. A token that carries no readable audience does not, because not every issuer sets one, and refusing what cannot be read would take every connected agent down at once.

## The token carries a person, not a key

The role on the membership row is read live at call time rather than trusted from a claim in the token. A person demoted this morning is a demoted caller this afternoon, without waiting for a token to expire.

The workspace is likewise derived from the authenticated session rather than from a field in the request. An agent cannot name a workspace it was not authorized for and be believed.

## Revoking

A workspace owner or admin can revoke a connected client in Settings. This blocks that client for every teammate in that workspace on its next authenticated request. Other workspaces keep their access, and the shared OAuth application is not deleted.

Restoring access is a separate action in the same screen. It permits the client's existing, otherwise valid authorization to work again. Revocation and restoration are audited; neither undoes completed work.

## What to read next

[Workspace setup](https://trysincerely.com/docs/mcp-setup) is the first call to make after authorization succeeds. [Confirmations](https://trysincerely.com/docs/mcp-confirmations) covers the second gate, which authorization does not open.

---

Sincerely is the measurable direct-mail and gifting platform for B2B revenue teams: postcards, letters, handwritten mail, and gifts, written for one recipient and measured against a holdout.

Contact Sincerely: https://trysincerely.com/contact

Agent routing index: https://trysincerely.com/llms.txt