Any client that supports remote MCP servers over Streamable HTTP with OAuth can connect to Concord. The server URL is the only configuration:
Prerequisites
- A Concord account that belongs to at least one workspace.
- The browser your client opens must be able to sign in to app.concord.ad. Authorization never signs anyone in by itself.
Client setup
When it first connects, Claude Code opens your browser to sign in and approve the connection (run /mcp in the session if it does not). The tools then appear as mcp__concord__askConcord, mcp__concord__prepareUpload, and mcp__concord__attachUpload. Add a custom connector from Settings → Connectors and paste https://api.concord.ad/mcp as the server URL. Claude registers itself with Concord and opens the approval screen.
Most clients take a JSON entry of this shape. The exact file and key names depend on the client.The client must support OAuth 2.1 with Dynamic Client Registration (RFC 7591) and PKCE. Clients that only accept a static bearer token cannot connect: Concord does not issue long-lived tokens. 2026-07-28 and the previous handshake-based revision 2025-11-25, which every released client negotiates today.
How authorization works
Concord is both the OAuth 2.1 authorization server and the MCP resource server, so the whole flow runs against api.concord.ad. Clients discover it on their own; you only see the approval screen.
The client calls the endpoint
The first unauthenticated request is answered with a 401 and a WWW-Authenticate challenge pointing at /.well-known/oauth-protected-resource/mcp.
Discovery and registration
The client reads the protected-resource and authorization-server metadata, then registers itself at /auth/mcp/register. Registration is open and needs no credentials.
You approve the connection
The browser opens Concord’s approval screen. It names the client, tells you what it will be able to do, and asks which workspace to connect if you belong to several.
The client receives a token
Standard authorization-code flow with PKCE. The only scope Concord grants is openid: the token identifies you, and your Concord permissions decide the rest.
What you are approving
A connection acts as you. It sees what you can see in Concord and can do what you can do, inside one workspace. Concord never holds broader platform access than the person who authorized the connection, and every change to a DSP still goes through Concord’s platform actions and your approval.
One connection, one workspace. A connection is pinned to the workspace you choose on the approval screen. Every call made through it acts in that workspace and no other. To point a client at a different workspace, connect it again and choose the other workspace; if you belong to several workspaces, the screen appears on every authorization so you can always re-pick. If you leave the pinned workspace, the connection stops working until you authorize it again. It never moves to another workspace on its own.
Approval is per user. Your approval does not extend to your colleagues. A client that later asks for more scopes is asked again.
Approve only what you connected yourself. The name on the approval screen is the one the client declared when it registered. Anyone can register a client and call it whatever they like, so the screen stops a silent authorization but does not prove who is asking. If an approval screen opens and you did not just connect a client, deny it.
Tokens and revocation
Tokens expire and are checked on every call. When one expires, the client re-runs authorization; if you had already approved it for a single workspace, no screen is shown.
Approvals cannot yet be reviewed or revoked from Concord’s settings. To revoke a connection, contact support@concord.ad. A client Concord disables loses access immediately, including for tokens it already holds.
Ask Concord · Limitations and troubleshooting 
