[FEATURE] Claude can reconnect to a broken MCP in a manner similar to how it performs other actions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I have an MCP (Atlassian) that frequently loses its connection. It's easy enough to reconnect but it would be easier and more natural if Claude could do it in his usual inimitable style. I asked him to write it up and as always, he did a fine job:
Problem
When MCP connections (e.g., Atlassian) drop due to authentication timeout, Claude currently:
- Detects the failure
- Tells the user "Could you reconnect with /mcp?"
- Waits for user to manually type /mcp, navigate menus, and reconnect
This breaks conversational flow and is inconsistent with how Claude handles other operations requiring permission.
Current Behavior
Claude: [tries to fetch wiki page] Error: Authentication failed Claude: "The connection dropped. Could you type /mcp to reconnect?" User: [types /mcp, selects service, chooses reconnect] User: "ok, try again" Claude: [retries operation]
This happens 5-10+ times per session with unstable MCP connections.
Proposed Behavior
Claude should be able to request reconnection directly, similar to other permission prompts:
Claude: [tries to fetch wiki page] Error: Authentication failed Claude: "The Atlassian MCP connection failed. Should I: 1) Reconnect and retry 2) Reconnect and don't ask again this session 3) Skip this operation" User: [selects option 1] Claude: [triggers reconnection, retries operation]
Benefits
- Consistency - Claude already asks permission for file operations, commits, destructive actions, etc. MCP reconnection should follow the same pattern
- Reduced friction - One click vs. typing command + navigating menus
- Better flow - Claude can bundle reconnection with retry logic automatically
- Session continuity - Option 2 ("don't ask again") lets power users avoid repeated prompts
Implementation Notes
- Should only apply within an active session (not across sessions - that would be a security concern)
- User authorization is still required, just with a better UX
- Could be limited to same-session reconnections for services already authorized
Related Issues
The underlying issue is MCP connection stability (frequent auth timeouts), but better reconnection UX would significantly improve the experience while that's being addressed.
Proposed Solution
See above.
Alternative Solutions
No response
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
No response
Additional Context
No response
bump
+1 for this feature. I'm developing an MCP server and experiencing the same issue. When I restart the Docker container running my MCP server, Claude Code loses the connection and requires manual reconnection via /mcp.
The current SSE transport stores sessions in memory, so any server restart invalidates all existing session IDs. Claude Code then fails with "Could not find session" but doesn't offer to reconnect automatically. Auto-reconnect would significantly improve the developer experience, especially during active development when server restarts are frequent.
Voting for this one. I use headless mode only. No chat, just comprehensive context, MCPs and permission setup. I’m getting low quality results for my prompts because turned out the MCP servers require reconnections from time to time. Would be great if Claude could take care of reconnecting and never spend tokens if MCPs aren’t connected.
+1 on this
+1
up +1
+1