Skip to main content
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.
Concord speaks MCP protocol revision 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.
1

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.
2

Discovery and registration

The client reads the protected-resource and authorization-server metadata, then registers itself at /auth/oauth2/register (Dynamic Client Registration). Registration is open and needs no credentials. It is rate limited per IP address; a client over the limit gets 429.
3

You approve the connection

The browser opens Concord’s approval screen, described below.
4

The client receives a token

Standard authorization-code flow with PKCE. Concord asks for openid and offline_access: the token identifies you, your Concord permissions decide the rest, and offline_access earns a refresh token so the connection stays alive without the browser.

​
The approval screen

You must be signed in to Concord in that browser. The screen shows:
  • Verified app or Unverified app. Concord verifies Claude and ChatGPT by their registered callback addresses. Any other client is unverified: its name was chosen by whoever registered it.
  • The question “Allow” followed by the app name, and what the app will be able to do: talk to the Concord agent on your behalf, read your campaigns and their performance, and upload files. Changes on your platforms still go through your approval in Concord.
  • Where you will be sent once you allow it.
  • The workspace: a choice of workspaces if you belong to several, or the one workspace it will reach.
  • For an unverified app, a checkbox confirming you started the connection yourself, required before Allow is enabled.
The approval screen asking to allow Claude on the Northlane Media workspace Click Allow to connect, or Deny to refuse. A denied request returns access_denied to the client.

​
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 are checked on every call. An access token lasts one hour; the client renews it with its refresh token, which lasts 30 days and is replaced on each use, so you are not sent back to the browser. If renewal fails, 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