Connecting an MCP Client with OAuth

AI clients that support MCP authorization — Claude, Cursor, and VS Code among them — can sign in to Allegro's MCP server with OAuth. You add the server's URL, the client opens a browser window, you sign in to Allegro and approve the connection, and the client receives a token that acts as you. There is no API key to create, paste, or rotate.

Server URLs

Server	URL	Who can connect
Tenant	https://acme.allegrocdp.com/mcp	Members of the acme organization (and super admins)
Landlord	https://allegrocdp.com/mcp	Super admins

Use the platform subdomain, not a custom domain. Custom domains such as members.acme.com serve your audience's sign-in, not MCP.

Connecting

1. Add the URL to your client as a remote MCP server. Leave the authentication settings empty — the client discovers everything it needs from the URL.
2. When the client asks you to sign in, it opens Allegro in your browser. Sign in to the dashboard if you aren't already.
3. Review the consent screen. It names the client, the organization (or Allegro platform for the landlord server), your account, and the website Allegro will send you back to. Only continue if you recognize that website.
4. Choose what the client can do, then click Allow.

Claude Desktop, for example, only needs the URL:

{
    "mcpServers": {
        "allegro": {
            "url": "https://acme.allegrocdp.com/mcp"
        }
    }
}

Read and write access

Access	Scope	Who can grant it
Read data	mcp:read	Everyone who can connect; always included
Change data	mcp:write	Organization admins on a tenant server; super admins on the landlord server

The consent screen only offers Change data when the client asks for it and you are allowed to grant it. Leave it unticked to keep the client read-only.

A connection never has more access than you do. Write tools check your role on every call, so a client you connected as an admin loses write access as soon as you are no longer an admin, even if you granted Change data.

Tokens and sessions

Access tokens last one hour, and clients refresh them on their own. A connection stays signed in as long as the client is used at least once every 30 days; after 30 days without use, you sign in again. Each connection only works on the server you connected it to: a token for acme.allegrocdp.com is refused by every other organization's server and by the landlord server.

Disconnecting

Open Settings → Connected apps in the dashboard to see each client you've connected, which organization it can reach, whether it can change data, and when it was last used. Click Disconnect to revoke it immediately.

Allegro also revokes connections for you when:

• you are removed from an organization (its connections end),
• you lose super admin access (landlord connections end), or
• your account is deleted (all connections end).

How discovery works

You don't need this to connect a client, but it helps when debugging one. The server follows the MCP authorization specification:

1. An unauthenticated request to /mcp returns 401 with a WWW-Authenticate header pointing at /.well-known/oauth-protected-resource/mcp.
2. That document names the same host as the authorization server.
3. The client reads /.well-known/oauth-authorization-server on that host for the authorize, token, and registration endpoints.
4. The client registers itself at /oauth/register (dynamic client registration) and signs you in with the authorization code flow and PKCE (S256 only).

Registration is open and grants nothing by itself; a client can only act as you after you approve it on the consent screen.

API keys still work

OAuth is an addition, not a replacement. Organization and platform API keys keep working as described in the MCP Server guide, and are still the right choice for unattended scripts and servers. Like OAuth, they only work on the platform subdomain: a custom-domain or per-property /mcp URL returns 404.

Related

• MCP Server — Tools, permissions, and API key authentication