Synq Docs
Guides

MCP

How MCP hosts such as Claude and Cursor sign people in, to Synq's own MCP server and to yours.

MCP hosts, such as Claude and Cursor, sign people in with OAuth 2.1, and they aren't apps anyone registered beforehand. Synq is their authorization server twice over: for its own MCP server, where your org's admins manage Synq from a host, and for your MCP servers, through your brand's issuer.

Synq's MCP server

Synq's MCP server is at https://api.synq.build/mcp (Streamable HTTP). Its tools read your orgs, brands, apps, users, audit log and webhooks, and make a few small changes that are easy to undo. Each is one management API call made as the person who signed in, so it has the same permissions, rate limits and audit rows as the API: MCP tools lists them, with the scope each needs.

A host connects like this:

  1. It calls https://api.synq.build/mcp and gets 401, whose WWW-Authenticate header names the server's protected-resource metadata (RFC 9728), at https://api.synq.build/.well-known/oauth-protected-resource/mcp. That names Synq's own issuer, https://accounts.synq.build, where people who run Synq orgs sign in.
  2. It registers itself there, and signs the person in with PKCE, as below.
  3. The person consents to what it asks for: every call needs synq.read, and a tool that changes something needs synq.write too.
  4. Its access token is for https://api.synq.build/mcp alone. A tool the token lacks the scope for answers 403 insufficient_scope, and a token for the MCP server never works on the management API, nor the other way round.

What tools return can include text anyone could have written, such as a user's chosen name, so the server marks it as tenant data. No tool touches secrets, keys, sessions, credentials or billing, deletes anything or adds a way into an account.

How a host signs people in

  1. It finds the issuer from the MCP server's protected-resource metadata, which a 401 points to.
  2. It registers itself. If it publishes a Client ID Metadata Document from an origin Synq accepts, its client ID is that document's URL and nothing is stored ahead of time. Otherwise it registers through open dynamic registration, at /reg on the issuer, which takes only a few registrations an hour from one address.
  3. It signs the person in with the authorization code flow and PKCE (S256), asking for the MCP server with resource.
  4. The person consents. A host is never one of the brand's own apps, so the person sees what it asks for and allows or refuses it. Synq remembers what they allowed, and it can be withdrawn later.

An app that registered itself is public (it has no secret), sends people back only to https or loopback redirect URIs, never a scheme of its own, asks only for authorization codes and refresh tokens, and gets no way to read or change its registration afterwards. It is a native app, so an http loopback redirect URI it lists, such as http://localhost/callback, takes any port, since a host on someone's computer listens wherever it can (RFC 8252); the rest of the URI must match exactly. It can reach only the APIs open to apps that aren't the brand's own, and only with consent. Synq removes one that hasn't been used for 30 days, or that never signed anyone in during its first day. A brand keeps at most 1,000 apps that registered themselves through /reg. Past that, /reg answers invalid_client_metadata until unused ones are removed, and your org's audit log and webhooks get brand.app_registrations_full, at most once an hour.

Putting your MCP server behind Synq

  1. Register your MCP server as an API of the brand, with its canonical URI as the identifier and the scopes it understands, and allow apps that aren't yours to ask for it. See Register an API.
  2. Serve its protected-resource metadata (RFC 9728), naming the brand's issuer, such as https://acme.auth.synq.build, and answer a request without a valid token with 401 and a WWW-Authenticate header that points to it.
  3. Check every access token: its signature against the issuer's keys (the jwks_uri in the issuer's discovery document), its iss, its aud (your MCP server's URI), its expiry and the scopes each tool needs.

On this page