MCP Unauthorized After Login: Trace the Token

A completed browser login does not prove that every later request has the right credential. The MCP client may need a token for the MCP server, while the server needs a separate authorization to call an external service. Trace which request returns the error before reconnecting accounts.

Identify the failing boundary

Write down the sequence: browser authorization, token exchange, client request to MCP, and server request to the downstream provider. Capture status codes and sanitized error categories at each boundary.

Never paste bearer tokens or refresh tokens into a ticket. Record issuer, intended resource, scope names and expiry only where those fields can be inspected safely.

The MCP authorization specification explains resource-oriented authorization. Use the specification revision negotiated by your client and server; a legacy example may not match a newer implementation.

Separate authentication from permission

A user can be correctly signed in but lack access to the requested project. A token can also be valid for one service and invalid for another.

Pattern	Investigation
Every MCP call fails immediately	Token delivery, intended resource, issuer
Discovery succeeds, one tool fails	Scope or tool-specific downstream access
Works initially, later fails	Expiry, refresh or revoked access
One account works	Account membership or resource selection

Status codes help narrow the search, but read the provider's error response: implementations do not always classify authorization failures identically.

Test the smallest permitted action

Choose a harmless read operation against a resource the user is known to access. Compare it with the failing operation using the same identity.

If the read works and a write fails, do not request an all-powerful credential by default. Determine the missing scope or application permission and whether the user's task requires it.

The MCP security guidance explains why blindly passing a client's token through to another service is unsafe. Fix the appropriate authorization flow.

Handle expiry deliberately

Check whether the client refreshes credentials through its supported mechanism. Compare machine clocks when timestamps appear inconsistent. If access was revoked, reauthorization may be appropriate; repeated reconnecting will not fix a server that requests the wrong resource.

Keep old and new configuration records free of secret values so you can identify what changed.

Confirm a stable result

Repeat the read test, then the authorized target action. Test again across the expected credential-refresh boundary in a controlled environment. Record the client and server versions and any provider-specific requirement.

Use the permissions audit to document effective access. The goal is a correctly scoped working action, not a login screen that merely reports success.

Related troubleshooting

• Can a Document Redirect Your AI Agent?
• MCP Connected but No Tools: What to Check

This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.