Local MCP Servers are not availble on Remote Control sessions

[Haoxuan_Li]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using Remote Control or a My Machines worker session, locally configured MCP servers (e.g. ModSDK MCP via stdio) appear connected in Cursor logs, but their tools are not exposed to the active agent session. The agent only sees cursor-cloud tools, even though the MCP server starts successfully and tool descriptors are cached on disk.

This breaks workflows that depend on local MCP servers (private APIs, local SDKs, ModSDK, etc.), which is a primary reason to use Remote Control / My Machines instead of a full Cloud Agent VM.

Also, since this MCP server is a local python server, i counldnt add it in cursor.com(just like others suggested)

Steps to Reproduce

Configure a local stdio MCP server in ~/.cursor/mcp.json (e.g. ModSDK MCP Server, which is MCP through local python for docs searching).
Confirm it works in a normal local Agent/Chat session in the Editor — MCP tools are available and callable.
Open the Agents Window (not the regular Editor chat).
Enable Remote Control under Settings → Agents.
Start or hand off an agent session with /remote-control, or start a My Machines worker with agent worker start and run a session from cursor.com/agents.
Ask the agent to use an MCP tool from the locally configured server (e.g. “search ModSDK docs” or “list available MCP tools”).
Observe that the agent cannot see or call ModSDK MCP tools.
Check Cursor MCP logs (e.g. mcp-server-user-ModSDK%20MCP%20Server.log) — the server shows as connected/healthy.
Inspect the agent session’s available tools — only cursor-cloud (and built-in tools) are listed; local MCP tools are missing despite a successful connection in logs.

Expected Behavior

Local stdio MCP servers configured for the workspace/user should be available in Remote Control and My Machines sessions, since tool execution runs on the user’s machine.
If the MCP server is connected (as shown in logs and tool descriptor cache), the agent session should expose those tools the same way a normal local IDE session does.
At minimum, behavior should match SSH Remote: local ~/.cursor/mcp.json is honored and MCP tools are callable without duplicating config in the Cloud Agents dashboard.

Actual behavior: MCP logs report a successful connection, but the agent session tool list does not include local MCP tools — only cursor-cloud tools are available.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.10.20 (user setup)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: Agent Window
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: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Any models

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

Hey there!

Getting locally-configured stdio MCP servers (like your ModSDK Python server) to appear in Remote Control / Agents Window sessions is a known rough edge we’re actively working on. Those sessions assemble their tool list differently from the regular editor, which is why ModSDK shows healthy in the MCP logs but its tools don’t show up in the session.

For now, the reliable way to keep using ModSDK is a normal Editor Agent/Chat session (the regular editor chat, not the Agents Window and not remote-controlled). Your local ~/.cursor/mcp.json is honored there and the tools are callable, which matches what’s already working for you.

If you want us to dig into your remote session specifically, could you share the MCP logs from that session (View > Output, then the “MCP Logs” and “MCP: ModSDK MCP Server” channels) plus a request ID from a run where the tools were missing? That shows whether the worker actually started your server, and I’ll take it from there.

[Haoxuan_Li]

Thanks!

I’m glad to hear that this issue is being actively worked on. I agree that this seems more like a logical design flaw rather than a specific bug, so there’s no need for a deep dive into my specific session.

That said, here is my Session ID in case it helps: bc-ed5ba034-c89d-45fb-9be8-3285aa9133e0. Since this is a remote-control session, I can’t see the full log output or the ID inside the IDE window(and the View->Output is not inside the agents window), so I might not be able to provide further logs. Feel free to tell me if I did wrong in finding the logs if thats really important.