[FEATURE] ability for claude ITSELF to restart MCP servers to allow testing

[Caleb-KS]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

I have claude code write MCP servers for various things. It's really good at it.

But when testing to make sure the mcp server works, it is annoying to constantly have to do /mcp and go reload the server.

Proposed Solution

provide a built-in tool that claude can call to reload an MCP server so it can

1. add mcp functionality
2. reload mcp
3. test mcp functionality
4. fix bugs
5. reload mcp
6. etc.

Alternative Solutions

right now, it tells me to do /mcp and reload.

other way is to tell it to call the mcp directly using powershell or something.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

No response

Additional Context

No response

[github-actions]

Found 3 possible duplicate issues:

1. URGENT: Claude Code CLI MCP reload broken for 6+ months - blocking all MCP development #7174
2. [Feature Request] Claude should be able to reconnect/reset MCP server #605
3. Feature Request: Add /reload-mcps Command for MCP Server Management #2756

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[Caleb-KS]

this request differs in that it's asking that CLAUDE be able to restart MCP servers instead of asking the user to run an /mcp command to restart a server.

[albahari]

Agree! We want to empower Claude to autonomously improve its tools. This is the next stage in AI.

What's required is very simple: the ability for Claude to stop and start an MCP server, so that it can run the following in a loop, without constant human intervention:

1. Identify an issue or missing feature in an MCP server under development
2. Stop the MCP server
3. Update and rebuild the MCP server
4. Restart the MCP server and test its new/improved features!

FWIW, I spent most of a day implementing a complex workaround using a proxying MCP server. Once it was working, watching the agent enter that feedback loop was amazing!

[alfhen]

+1 — I'm building Lien (getlien/lien), a local-first semantic code search MCP server designed for AI coding assistants like Claude Code. I dogfood it by having Claude Code connected to Lien from the same repo it's developing in.

I'm a huge fan of Claude Code — it's my primary development tool. But the workflow for MCP server development is genuinely painful:

1. Claude edits Lien's MCP server code
2. Claude builds it
3. I manually open /mcp, find the server, click reconnect — every single time
4. Claude tests the changes
5. Claude finds a bug, back to step 1

This loop happens dozens of times per session. Each manual intervention breaks Claude's autonomous flow and forces me to babysit what should be a fully autonomous edit-build-test cycle.

The infrastructure is already there. Looking at the internals, mcp_reconnect exists as an internal message type in the SDK/headless layer. ListMcpResourcesTool and ReadMcpResourceTool already let the agent interact with MCP servers. Adding a RestartMcpServerTool that sends an mcp_reconnect message would be a minimal change:

RestartMcpServer(server_name: string) -> { success: bool, tools_discovered: string[] }

The existing permission model (allowedMcpServers, deniedMcpServers, isStrictMcpConfig) already handles security. Session-scoped, no config mutation needed.

This would also make Claude Code the first MCP client to offer agent-invokable server restart — even OpenAI's Codex CLI has an open request for the same capability but hasn't shipped it yet.

Related issues that would benefit: #14067, #24057, #24386, #17975, #4118

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.