> ## Documentation Index
> Fetch the complete documentation index at: https://docs.concord.ad/llms.txt
> Use this file to discover all available pages before exploring further.

# Connecting a client

> Point your MCP client at Concord, sign in, and approve the connection.

Any client that supports remote MCP servers over Streamable HTTP with OAuth can connect to Concord. The server URL is the only configuration:

```
https://api.concord.ad/mcp
```

## 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](https://app.concord.ad). Authorization never signs anyone in by itself.

## Client setup

<Tabs>
  <Tab title="Claude Code">
    ```bash theme={null}
    claude mcp add --transport http concord https://api.concord.ad/mcp
    ```

    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`.
  </Tab>

  <Tab title="Claude Desktop and claude.ai">
    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.
  </Tab>

  <Tab title="Other clients">
    Most clients take a JSON entry of this shape. The exact file and key names depend on the client.

    ```json theme={null}
    {
      "mcpServers": {
        "concord": {
          "url": "https://api.concord.ad/mcp"
        }
      }
    }
    ```

    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.
  </Tab>
</Tabs>

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.

<Steps>
  <Step title="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`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/features/platform-actions/platform-actions-overview) 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.

<Warning>
  **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.
</Warning>

## 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](mailto:support@concord.ad). A client Concord disables loses access immediately, including for tokens it already holds.

## Related

[Ask Concord](/developers/mcp/ask-concord) · [Limitations and troubleshooting](/developers/mcp/limitations)