With Browser Automation set to Browser Tab, the agent context / MCP catalog can advertise cursor-ide-browser (and ~/.cursor/projects/<ws>/mcps/cursor-ide-browser/ can briefly show tool descriptors with toolCount=16), but CallMcpTool / GetMcpTools({server:"cursor-ide-browser"}) fail with:
Error: MCP server "cursor-ide-browser" not found. Available servers: cursor-app-control, plugin-…, user-…
Split-brain in the same session: pattern catalog can report serverStatus=ready while direct calls fail. Toggling Browser Automation Off→On does not restore tools to an existing agent chat (new chat sometimes works). Reproduced on first browser use in home/empty-window and again from a project workspace — not only after long automation.
Steps to Reproduce
Open Agent chat (home/empty-window or project workspace) on Cursor 3.13.21
Observe CallMcpTool fails with MCP server “cursor-ide-browser” not found while other MCP servers remain available
Optionally: watch Mcp FileSystem Writer logs show join/leave lease with toolCount=16 then “left the lease”
Toggle Browser Automation Off then On again — existing chat still has no cursor-ide-browser
Expected Behavior
If cursor-ide-browser is advertised to the agent (prompt + disk catalog), CallMcpTool should succeed. Catalog discovery and runtime registration must not disagree. Toggling Browser Automation should refresh the current agent session (or clearly require a new chat).
Operating System
MacOS
Version Information
IDE:
Version: 3.13.21
Commit: 55434bd8062ece6fee083b82beed2aee42d253f0
OS: Darwin arm64 25.5.0
Brave is system browser.
For AI issues: which model did you use?
Cursor Grok 4.5
For AI issues: add Request ID with privacy disabled
N/A — failure is MCP routing / Browser Automation wiring (“server not found” / wrong tab), not a model completion error.
Why a new report: closest threads cover mid-session ~5min lease drops (/t/159736), zero tools while connected (/t/158762), or older access issues (/t/150919). This is cold-start / catalog-vs-runtime on 3.13.21, including toggle not refreshing an existing chat.
Privacy Mode / data sharing is on. Attaching sanitized local logs that show the catalog/disk vs runtime gap for this report.
What the logs show (catalog side)
On empty-window workspaceId=b23abea01bc4771017b008369920af3f, MCP FileSystem Writer repeatedly:
Writes cursor-ide-browser with toolCount=16 (catalog looks healthy)
Then Server "cursor-ide-browser" left the lease, scheduling directory removal
Re-adds with toolCount=16 again — churn throughout the morning (07:00–07:20 local)
While that catalog churn is happening, agent CallMcpTool still returns MCP server "cursor-ide-browser" not found in the agent runtime (this thread’s primary bug).
Extra signal in project writers (workspaceId=c63b395f…): ENOENT writing cursor-ide-browser~staging under a different project path (…/stocktextalerts-sfeo/…) — disk catalog write targeting the wrong workspace.
Session / identity (data sharing on)
machineId:45f9fb3f-e7a9-4793-a235-3a7bb93e4e3f
Cursor: 3.13.21 (55434bd8062ece6fee083b82beed2aee42d253f0) Darwin arm64
This is a real bug on our side (not your setup), and it’s a known class we’ve been tracking. The short version: the cursor-ide-browser server can be advertised in the catalog and on disk while the live registration the agent actually calls into transiently drops it at submit time. The catalog/disk state and the live-runtime state can legitimately diverge for short windows, which is why CallMcpTool fails while everything on disk looks healthy.
Two things that should unblock you today:
Reload the window (Command Palette → Developer: Reload Window). This has consistently restored the live registration on this class of report. As you noted, toggling Browser Automation Off→On isn’t reliable for an existing chat — a full reload is.
If the tools come back but the browser view feels stale after sleep/wake or a long session, call browser_navigate with newTab: true as the very next action. That forces the underlying browser view to rehydrate rather than reusing a stale view ID.
I’ve reported your case (with logs and the cold-start pattern) to our team.
Two quick asks if you hit this again after a reload:
Does browser_navigate with newTab: true (as the very first browser call) succeed, or does it also fail with server-not-found?
If it fails, does the file ~/Library/Application Support/Cursor/logs/<session>/window*/Mcp FileSystem Writer.workspaceId-<id>.log show lease returned 0 tools across 0 clients at the moment of the failing CallMcpTool, or is the lease showing tools but CallMcpTool still fails?
Either answer helps localize whether the fix in review will resolve your specific flavor.
14:49:57.882 — Server "cursor-ide-browser" left the lease, scheduling directory removal
lease then 179 tools across 9 clients (browser gone, other MCPs still present)
Later (14:55:04) browser sometimes reappears with toolCount=16, then drops again later
Cursor is also mentioning there is a lot of browser tool churn: 2309cursor-ide-browser left the lease events in this log session folder.
Happy to provide more info if that will help, thanks!