GetMcpServerStatus reports some MCP servers as needsAuth / authentication_required. Calling AuthenticateMcpServer for those servers returns that they are already authenticated and connected and shows a confirmation card — but GetMcpServerStatus still shows needsAuth afterward. RestartMcpServers does not clear the mismatch. Sibling servers from the same plugin can be connected while one account stays needsAuth.
Observed examples (2026-09-07):
user-Cloudflare-docs: needsAuth (plugin 407) while Cloudflare-bindings / builds / observability on the same plugin are connected
user-Fastmail–john: needsAuth while Fastmail tools often still work
Steps to Reproduce
GetMcpServerStatus → note a server with needsAuth (e.g. user-Cloudflare-docs).
AuthenticateMcpServer for that server_id.
Observe “already authenticated and connected” / confirmation card.
GetMcpServerStatus again → still needsAuth.
Expected Behavior
Status and AuthenticateMcpServer agree; if already connected, status is connected. If needsAuth, Authenticate opens a real auth flow.
Actual Behavior
AuthenticateMcpServer says already connected (confirmation card), but GetMcpServerStatus remains needsAuth / authentication_required. RestartMcpServers does not clear it. Sibling servers from the same plugin can be connected while one stays needsAuth.
Screenshots / Screen Recordings
None attached.
Operating System
darwin (reporter Mac) / Grok Bot cloud computer also shows the status
Hey @jsolly, thanks for the report. This isn’t intended behavior, and it’s an issue we’re already tracking.
The badge only counts an OAuth sign-in as “authenticated,” so connectors that don’t use OAuth (Cloudflare docs is fully public, Fastmail uses an API token) show “needs auth” even though they’re connected and their tools run. It’s cosmetic - those tool calls should still work. Authenticate just confirms the connection and a restart re-reads the same state.
If the badge is getting in the way (e.g. other bots skipping the connector), removing the account entry for it under Settings → Plugins clears it - but it comes back if Authenticate runs on it again, so best to leave those two as-is. I’ll follow up here when there’s an update.
Update (2026-09-08): Fastmail connector UI still shows Needs auth, and Authenticate now toasts Fastmail didn’t provide a sign-in link.
Details from the plugin / MCP settings page:
Account default: Needs auth
Source: Added manually
Transport: HTTP
URL: https://api.fastmail.com/mcp
Tools listed as 29 of 29 enabled in the UI, but auth badge stays Needs auth
Toast: Fastmail didn’t provide a sign-in link
This matches the stuck badge / no browser sign-in link behavior already discussed on the Cursor email ticket (T-F57139): connectors that never complete a browser OAuth still sit on needsAuth, and Authenticate / force re-authorize return no sign-in link.
Update from Cursor support (Parth)
The Fastmail Needs auth badge + “didn’t provide a sign-in link” toast while tools still work (29 tools enabled / live calls succeed) matches a badge-mismatch display bug they are already tracking — not a broken connection. Retrying Authenticate does not clear the badge.
We confirmed: Fastmail MCP calls succeed despite needsAuth / authentication_required in status. Stopping Authenticate retries for Fastmail; still watching for the badge fix.
