Revoking an MCP server’s access usually means clicking one button — but which button, and where, changes what actually happens. A grant you approved once can live in up to three separate places at the same time: the vendor’s own OAuth settings, your AI client’s local connection list, and, if you connect through a gateway, the gateway’s own record of that grant. Revoking in one place doesn’t automatically revoke it in the others. Here’s where a grant actually lives, how to pull it from each place, and what “revoked” does and doesn’t guarantee.

Where a grant actually lives

When you approve an MCP server’s OAuth consent screen, three things typically get written down, not one:

  • The vendor’s authorization server records that your account granted a token to that client — this is the source of truth. Revoking here is the only action that can make the vendor’s own servers reject the token outright.
  • Your AI client (Claude, ChatGPT, Cursor) stores the resulting access and refresh tokens locally so it doesn’t need you to log in again on every request. Removing the connection here stops that client from using it, but doesn’t touch the vendor’s record.
  • A gateway, if you use one, keeps its own record of which client connected to which server and when it was last used — separate from both of the above, because it’s the thing brokering the connection in the first place.

None of these three is automatically aware of the other two. That’s the part that catches people out: clearing a connection from your AI client’s settings feels like “done,” but the token the vendor issued can still be valid until you revoke it at the source.

Revoking at the vendor

This is the one that actually matters most, and it works basically the same way across services: log into the account directly (not through the AI client), find the connected-apps or authorized-integrations page — usually under security or application settings — and remove the entry for your AI client or MCP connector by name. This invalidates the underlying token at the source, which is the only revocation that’s guaranteed to stop every place that token might otherwise still work.

If you don’t recognize the client name in that list, or see one you never approved, that’s worth investigating on its own — it’s one of the signals we cover in how to tell a real MCP server from a fake one.

Revoking at the AI client

Most clients let you remove a connected MCP server from their own settings or connector list. This stops that specific client from calling the server going forward, and it’s worth doing for hygiene — a stale entry pointing at a server you no longer use is one more thing that can silently reconnect on an update. But on its own, this step doesn’t reach the vendor’s authorization server. If the token hasn’t expired and nothing revoked it upstream, in principle it’s still valid — the client removal just means nothing in front of you is using it anymore.

What revoking doesn’t always cover

We wrote separately about MCP token passthrough, where a server forwards the caller’s own token straight to its backend instead of issuing its own scoped one. That pattern makes revocation murkier still: if a token was ever forwarded downstream to a second service, revoking it at the original identity provider may not reach every place a cached copy is still sitting. You mostly can’t verify this from the outside — it’s server implementation behavior, not something the consent screen tells you.

The practical takeaway isn’t to distrust every revoke button. It’s to revoke at the vendor first, since that’s the one place with the authority to actually invalidate the token, and to treat a client-side removal as cleanup rather than the whole job.

If you connect through a gateway

A gateway adds a fourth place worth checking, and it’s useful for a specific reason: it’s the one record that shows which AI clients actually hold a live grant for a given server, in one list, instead of you having to remember and check each client separately. In gate, each connected AI client shows up against the server it’s using with when it was last active, and revoking it there marks the grant revoked on gate’s side immediately — useful when a client stops using a server, or when someone leaves a team and you want their access gone without hunting through individual laptops for local client configs. It’s still not a substitute for revoking at the vendor if the underlying token itself needs to be invalidated; it’s the layer that controls whether the gateway will keep honoring that grant going forward. See gate’s security page for how that fits alongside scanning and drift detection, and the MCP gateway page for how the gateway model works more generally.

How to tell if a revoke actually worked

The most reliable check is the boring one: after revoking, try using the server from the client again. If it prompts you to re-authenticate, the revoke reached the token. If it keeps working with no new prompt, something upstream is still honoring the old credential — worth revisiting the vendor’s connected-apps list directly rather than assuming the client-side removal was enough. A readable log of what a client actually called, and when, also makes this easier to notice than staring at a settings page — which is part of why we built gate’s call log the way we did, and part of what a scan with gate’s free MCP security scanner is meant to surface before you connect a server in the first place.

The bottom line

A single “disconnect” click rarely reaches every place a grant is recorded. Revoke at the vendor first — that’s the only place with the authority to invalidate the token itself — then clean up the client-side connection, and check your gateway’s grant list if you use one. When in doubt, test it: try the tool again and see whether it actually asks you to log back in.