You add a remote MCP server, click connect, and instead of a sign-in screen you get an error — unauthorized_client, or the OAuth screen just never shows up. Nothing about your setup is wrong. Some MCP servers only accept OAuth connections from a client the vendor has approved in advance, and yours isn’t on that list yet. Here’s why that happens and what actually gets you connected anyway.
What’s actually going on
MCP’s OAuth flow is built on a spec that supports dynamic client registration — any client can register itself with a server on the fly and get its own client ID, no prior relationship needed. That’s what makes one-click “Connect” buttons possible for servers like Notion or Linear.
Some vendors don’t turn that on. Instead, they keep a manual allow-list of client IDs they’ve reviewed and approved, and reject anything else at the authorization step. That’s a deliberate choice, usually about controlling which apps can request access to a company’s data, not a bug in the server or in the client trying to connect to it. It’s the same gap covered in MCP OAuth scopes explained: a server supporting OAuth in principle isn’t the same claim as every client being able to walk through it today.
How common this actually is
In gate’s own catalog of remote MCP servers, 18 out of 51 are marked restricted — meaning their OAuth currently only admits clients the vendor has allow-listed, rather than any client that asks. That list includes some large, well-known names: Figma, Canva, Asana, ClickUp, HubSpot, Slack, Vercel, Dropbox, Spotify, and more. It isn’t a fringe problem confined to obscure servers — it’s a real fraction of the ecosystem, and it changes over time as vendors expand their allow-lists.
Three ways to get past it
1. Wait and retry
Allow-lists grow. A client that’s rejected today may be approved next month with no change on your end. If the server matters but isn’t urgent, retrying the connection occasionally is a legitimate strategy, not a workaround.
2. Use a client the vendor already allows
Some vendors allow-list a handful of major AI clients directly and nothing else. If your AI client of choice isn’t one of them but another client you also use is, you can connect through that one instead — not ideal, but functional.
3. Use an API key instead of OAuth
For servers that support it, a personal access token or API key sidesteps the OAuth allow-list entirely — you’re authenticating with a credential the vendor issued you directly, not asking their OAuth server to recognize your client. GitHub’s MCP server is the clearest example: it doesn’t do one-click OAuth for third-party clients at all, so a personal access token is the normal way in, not a fallback — see connecting GitHub to Claude for the walkthrough. Atlassian and Slack also accept an API token or app token as an alternative when their OAuth step doesn’t complete.
gate added this as a fallback directly on the server page: if a connection sits at “needs reauth” because the vendor’s OAuth rejected the client, the panel offers “Use an API key instead” alongside “Retry sign-in,” with a vendor-specific hint for where to generate one. The key is validated against the server’s tool list before it’s stored, so a bad or over-scoped token gets caught immediately rather than failing silently later.
What an API key gets you that OAuth doesn’t — and what it costs
A personal access token is usually broader than a scoped OAuth grant, and it doesn’t expire the way an OAuth token typically does, so it keeps working without a re-consent prompt. That convenience has a real tradeoff: it’s on you to scope the token narrowly at creation time and to revoke it yourself if the connection is ever removed, since nothing automatically ties its lifetime to the MCP server it was created for. Treat a pasted API key the same way you’d treat a password — it should never be logged or shown in plain text after you’ve entered it, in gate or anywhere else.
Checking whether a server needs this before you try
Rather than discovering the allow-list wall mid-flow, gate’s MCP servers directory marks each entry’s current connectivity — one-click OAuth, API-key based, or allow-list restricted — so you know what kind of setup to expect before you start. You can also run any server’s URL through gate’s free MCP security scanner to check its tool list for prompt injection or hidden instructions before connecting, independent of which auth method it ends up using.
The bottom line
An “unauthorized client” error on an MCP connection almost always means the vendor’s OAuth hasn’t opened up to your client yet, not that anything is broken. Retry later, try a different allowed client, or — for servers that support it — use a personal access token or API key to connect directly. None of those is a workaround in the bad sense; they’re the normal ways to get access to a server that hasn’t turned on open client registration yet.