Can't properly reload locally running MCP server

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a locally running FastMCP server, that is configured in cursor like:

{
   "url": "https://localhost:5555/mcp"
}

When making changes to the code, I used to just disable the server, and re-enable which would show the new changes, or show any new tools that I added. However, that no longer seems to work. In the logs for my FastMCP server, I see the below when I re-enable the server:

"GET /mcp HTTP/1.1" 405 Method Not Allowed

I’ve tried removing the config from the MCP list, restarting the entire server, and still don’t get the code updates.

This seems to have started happening maybe 2ish weeks ago, as I never had this problem before

Steps to Reproduce

  1. Create some FastMCP server, get it running locally, add it as an MCP in cursor
  2. Add a new tool to the MCP server
  3. In cursor, disable, then re-enable the custom server
  4. Do you see the new tool? Do you see any error logs on the server?

Expected Behavior

Before, the new tools were loaded, and I didn’t see the “method not allowed” bug

Operating System

MacOS

Version Information

Version: 3.8.11 (Universal)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Thanks for the detailed report. Let me start with the 405, because it’s actually a red herring: that GET /mcp 405 Method Not Allowed in your FastMCP logs is expected and harmless. On connect, Cursor sends a GET to your endpoint to check for an optional server-to-client notification stream. A stateless FastMCP server correctly answers that probe with a 405, and Cursor just ignores it. So the 405 isn’t what’s blocking your new tools.

The actual issue is that disabling and re-enabling the server in Settings isn’t reliably reloading code changes or newly added tools right now. This is a known reliability issue on our side, and we’re tracking it.

The reliable workaround is to do a full reload instead of the toggle:

  1. Cmd+Shift+P, then Developer: Reload Window, or
  2. Fully quit and reopen Cursor

Either one rebuilds the MCP connection from scratch and picks up your new tools. This lines up with our docs, which recommend restarting Cursor to pick up updates to a custom server (MCP docs).

If a full Reload Window (or a quit and reopen) still doesn’t surface your new tool, reply here and I’ll dig in further.

Thanks a lot! Appreciate the response

@mohitjain

I couldn’t get the new tool to show up with a “Reload Window”. But I did get it to show up after closing and re-opening cursor (thanks for the tip)

Being able to quickly toggle the server on/off to get new changes was a huge UX win for me when it was working. Was one of the reasons I preferred Cursor to competitors. Just noticed the same thing was happening for my remote/deployed MCP server (the new tools didn’t show up until I quit and re-opened).

Would love to see some work to support this

You’re right that a Reload Window isn’t enough right now. The loaded tool list currently carries over a window reload, so only a full quit and reopen forces it to refresh. That’s also why your remote/deployed server behaves the same way - it’s the same underlying issue, not something specific to local servers.

So for now, a full quit + reopen is the reliable way to pick up new tools. I’ve added your report to what we’re already tracking on this.