> ## Documentation Index > Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt > Use this file to discover all available pages before exploring further. # Fix a Broken or Stale MCP Connection > How to fix a remote MCP server connection that worked before and then broke because of a stale authorization held on the provider's side. Recognize the symptoms — an identity flagged Needs authentication or Disconnected, tool calls returning a re-authentication error, and no provider consent screen when you retry — then re-authenticate from Settings, and when that isn't enough, deauthorize MCP Manager's app on the provider and use Authenticate again to force a fresh authorization (which moves your gateways and connections onto the repaired identity automatically). Applies to any OAuth-based server, shown with Asana as the worked example. 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](/advanced/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](/build-your-own-mcp-server/debugging-self-hosted-oauth) and the [stale dynamic-client registration edge behavior](/security/authentication-and-identity#edge-and-failure-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](https://app.mcpmanager.ai/settings/servers) 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](/security/authentication-and-identity#identity-authentication-statuses). 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 In MCP Manager, go to the [Servers](https://app.mcpmanager.ai/settings/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. 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](#where-to-deauthorize-by-provider)); 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. 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. 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. | Provider | Where to deauthorize MCP Manager's app | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Asana** (worked example) | Settings → **Apps** → **Authorized Apps** → the MCP Manager app (e.g. "Asana MCP company-wide") → **Deauthorize** | | **Atlassian, Slack, and other OAuth providers** | In the provider's account or security settings, find connected / authorized / third-party apps and remove the MCP Manager entry | | **Google** | Usually unnecessary — MCP Manager forces a fresh consent screen for Google servers on every re-authorization (see the note above) | 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](/advanced/gateway-resiliency) or a self-hosted server that lost the client MCP Manager registered ([debugging self-hosted OAuth](/build-your-own-mcp-server/debugging-self-hosted-oauth)). ## Further reading When an identity's credential stops working versus a plain server outage, and how each is surfaced. How MCP Manager stores credentials, refreshes tokens automatically, and what happens when a refresh fails. The guided, server-by-server connection flow and how saved identities are reused. Confirm a server and its credentials work in isolation with an open inspector before diagnosing further. How MCP Manager detects a server's authentication type, and the per-server connection guides. The Asana setup guide — registering the app, Client ID and Secret, and the OAuth approval.