mcp-hmr: Send notifications/tools/list_changed after hot-swap

[richardpowellus]

When mcp-hmr hot-swaps the inner app (unmount old proxy → mount new proxy on base_app), it does not send a notifications/tools/list_changed notification per the MCP spec.

The client caches its tool list from the initial tools/list call and never re-queries it, so newly added or removed tools are invisible until a full server restart — which defeats the purpose of hot reload.

Expected

After each hot-swap, mcp-hmr should send notifications/tools/list_changed so the client refreshes its tool cache.

Reproduction

1. Start a server via mcp-hmr src.server:mcp -t stdio
2. Add a new @mcp.tool() function in a new or existing module
3. Save the file — mcp-hmr detects the change and hot-swaps
4. Call the new tool → Tool does not exist (client still has stale cache)
5. Restart the server → tool now appears

Workaround

We use a wrapper script that monkey-patches ServerSession.__init__ to capture the active session reference, then monitors base_app._mounted_servers for changes and calls session.send_tool_list_changed() after each swap.

Environment

• mcp-hmr 0.0.3.3
• fastmcp 2.14.6
• MCP client: GitHub Copilot CLI (stdio transport)

[coderabbitai]

🔗 Related PRs

#39 - mcp-hmr [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[CNSeniorious000]

Thanks so much @richardpowellus! I’d been running into the same issue for a long time too but never fixed it because I couldn’t find a clean way to get the session reference.

Just opened #80. Feel free to review it if you have a moment. If nothing unexpected comes up, I’ll likely release it tomorrow.

[richardpowellus]

Looks great — this matches the approach we've been running as a workaround and it's worked reliably. A few small observations:

• gather + tg.create_task is a bit redundant since the TaskGroup already awaits its children, but no harm done.
• patch_session_init is missing from __all__ — worth adding since the README documents importing it directly.

Neither is blocking. Thanks for the fast turnaround on this! 🎉

[CNSeniorious000]

Thanks! Released in v0.0.3.4

[CNSeniorious000]

Quick update: just released v0.0.3.5. mcp-hmr now patches ServerSession.__init__ only while its managed FastMCP session is being initialized, and restores the original initializer immediately afterward. That keeps the monkey-patch much more tightly scoped, so manual patch_session_init() is no longer needed.

hmr/packages/mcp-hmr/mcp_hmr.py

Lines 26 to 33 in 2b85661

	def _capture_session_init(self: ServerSession, *args, **kwargs):
	original_session_init(self, *args, **kwargs)
	active_sessions.add(self)
	global _pending_patches
	_pending_patches -= 1
	unpatch()

hmr/packages/mcp-hmr/mcp_hmr.py

Lines 58 to 69 in 2b85661

	original_run = base_app._mcp_server.run # noqa: SLF001
	async def run_with_patched_session(*args, **kwargs):
	unpatch = patch_session_init()
	try:
	await original_run(*args, **kwargs)
	finally:
	unpatch()
	base_app._mcp_server.run = run_with_patched_session # noqa: SLF001