Skip to main content
A remote MCP server that connected fine and later stopped working is almost always an authentication problem, not an outage. The most stubborn version is a stale authorization on the provider’s side: the provider — Asana, Atlassian, Slack, and so on — is holding an old authorization for MCP Manager that no longer works, and it keeps handing that same dead authorization back instead of prompting you to authorize again. Reconnecting inside MCP Manager alone doesn’t clear it. This page shows how to recognize that case and fix it.
This page is for a connection that worked before and then broke. If instead a server is temporarily down or unreachable, that’s an outage — see Gateway Resiliency. If you’re running your own server and the OAuth step fails because the server lost the client MCP Manager registered (often a “client not registered” error), that’s a different problem — see Debugging self-hosted OAuth and the stale dynamic-client registration edge behavior.

​
Recognize a stale connection

You’ll see some combination of the following:
  • The identity shows a broken-status badge. On the server’s Identities tab, the identity for the affected server is flagged — Needs authentication while its credential might still recover, or the terminal Disconnected once a definitive rejection has archived the stored credential (a transient blip shows a shorter-lived Not connected). See what each status means. MCP Manager also stops offering a broken identity as an automatic choice, and makes it non-selectable in the connection flow — it never silently picks a credential it knows is broken.
  • Tool calls fail with a re-authentication error. In your AI client, a call to that server comes back with:
    MCP Manager needs ‘Asana’ to be re-authenticated before this request can complete. Visit your gateway settings to reconnect.
  • Nothing about your setup changed. The failure persists even though your Client ID and Client Secret are unchanged and still correct. Because you set this connection up successfully before, a message pointing you at your credentials is usually a red herring for this failure — what changed is the authorization on the provider’s side, not your app registration.
  • The tell: no consent screen on retry. When you try to reconnect (below), the provider’s consent screen doesn’t appear — the authorization tab flashes and closes in about a second — and the connection still fails. That near-instant, no-consent round trip is the fingerprint of a stale authorization: the provider auto-approves an authorization it already has, then rejects the token it just issued.
If the reconnect in Step 1 below does show a real consent screen and then works, you had an ordinary expired token, not a stale authorization — you’re done. The rest of this page is for when the consent screen never appears.

​
Why it happens

MCP Manager refreshes OAuth tokens automatically, so a healthy connection keeps working without you re-authenticating. A connection goes stale when the authorization on the provider’s side is gone or blocked while the provider still treats its app authorization as active. Common triggers:
  • You changed your password or your security settings with the provider.
  • An administrator at the provider revoked or blocked the app.
  • You removed the account, workspace, or app that the original authorization was tied to.
  • For providers that rotate refresh tokens on a fixed schedule, the authorization simply reached the end of its life — roughly every 90 days for some (Atlassian, for example), which makes this a routine re-authentication rather than a one-off failure.
Re-adding your identity inside MCP Manager often isn’t enough on its own. MCP Manager reuses one registered OAuth application per server and, for most providers, does not force the provider to show its consent screen again. It also has no way to revoke its own authorization on the provider for you. So if the provider still holds a stale authorization, a fresh attempt is silently auto-approved against that same dead authorization. The one action that reliably clears it is to deauthorize the app on the provider’s side, which forces the provider to prompt for consent the next time — and that is something only you, or a provider administrator, can do.
Google-backed servers are the exception. MCP Manager always forces a fresh consent screen when you re-authorize a Google server, so the provider-side deauthorize step below is usually unnecessary for them — a straight reconnect (Step 1) is normally enough.

​
Fix it

1

Try re-authenticating first — and use it to diagnose

In MCP Manager, go to the Servers page, open the affected server, and on its Identities tab open the broken identity and click Authenticate again (or, for a brand-new identity, Add a new identity). For an OAuth server this launches the provider’s authorization in a new browser tab. Watch that tab:
  • If the provider shows its consent screen, you approve it, and the connection starts working — you’re done. This was an ordinary expired token, and Authenticate again has already moved your gateways and connections onto the repaired identity.
  • If the tab flashes and closes with no consent screen, and the connection still fails, the provider is holding a stale authorization. Continue to the next step.
2

Deauthorize MCP Manager's app on the provider

This is the load-bearing step — it forces the provider to prompt for consent again next time. The exact location differs per provider (see the table below); the pattern is always to remove MCP Manager’s authorization in the provider’s connected-apps settings.In Asana, for example: click your avatar to open Settings, choose Apps in the left column, find the MCP Manager app under Authorized Apps (named something like “Asana MCP company-wide”), and click Deauthorize.
If several apps look similar, match the one whose last activity date lines up with roughly when your connection stopped working.
3

Re-authenticate the identity

Back in MCP Manager, on the same Identities tab, open the affected identity and click Authenticate again, then confirm Yes, re-authenticate. This time, because you deauthorized on the provider’s side, the provider shows a real consent screen — approve it.Because identities are write-once, MCP Manager mints a new identity with brand-new credentials that no longer reference the stale ones, then moves your gateway assignments and connections onto it automatically and retires the old one — so you don’t have to re-select the identity everywhere it was used.
Authenticate again repairs your own OAuth identities, and is the preferred fix because it carries your existing uses over for you. If the identity is a shared (Global) service account or authenticates with a header token rather than OAuth, re-establish it instead by updating its credential or adding a new identity — in this release the automatic move-your-uses-over step applies to your own OAuth identities.
4

Verify the connection is healthy

The identity’s broken-status badge (Needs authentication or Disconnected) should clear, and a tool call to the server should now succeed from your AI client.

​
Where to deauthorize, by provider

The step that actually clears a stale authorization is removing MCP Manager’s authorization in the provider’s own settings — look for connected apps, authorized apps, or third-party access. The location varies by provider, and the provider’s own documentation is authoritative for the exact path.
Some providers expire authorizations on a fixed schedule — roughly every 90 days for Atlassian, for example — so this kind of re-authentication can be a routine, recurring event rather than a sign that something is broken.

​
Still not connecting?

If a fresh consent screen still doesn’t restore the connection, the cause is likely outside your control as an individual user:
  • Ask a provider administrator to check the app’s status. The app may be blocked or pending approval at the organization level in the provider’s app-management settings — something a single user can’t clear.
  • Contact the provider’s support with the timestamps of the failed attempts and, if you have it, the exact error the provider returned (for example, an invalid_grant response from its token endpoint). A connection problem rooted in how the provider works is fastest to resolve at the source.
  • Contact MCP Manager support if you believe the problem is on the MCP Manager side — include the correlation ID from the error so the request can be traced.
This flow clears the most common cause of a broken connection — a stale authorization on the provider’s side. It does not address a provider outage or a self-hosted server that lost the client MCP Manager registered (debugging self-hosted OAuth).

​
Further reading

Gateway Resiliency

When an identity’s credential stops working versus a plain server outage, and how each is surfaced.

Authentication & Identity

How MCP Manager stores credentials, refreshes tokens automatically, and what happens when a refresh fails.

Connection Experience

The guided, server-by-server connection flow and how saved identities are reused.

Validate MCP Servers

Confirm a server and its credentials work in isolation with an open inspector before diagnosing further.

Find & Connect MCP Servers

How MCP Manager detects a server’s authentication type, and the per-server connection guides.

Connect Asana

The Asana setup guide — registering the app, Client ID and Secret, and the OAuth approval.