# My Machines / Remote Control: route localhost streamableHttp MCP via the worker, not Cursor cloud backend

**URL:** <https://forum.cursor.com/t/my-machines-remote-control-route-localhost-streamablehttp-mcp-via-the-worker-not-cursor-cloud-backend/170701>\
**Category:** Feature Requests\
**Tags:** mcp, remote-control, cloud-agents\
**Created:** [September 5, 2026, 2:12pm UTC](https://forum.cursor.com/t/my-machines-remote-control-route-localhost-streamablehttp-mcp-via-the-worker-not-cursor-cloud-backend/170701 "2026-09-05T14:12:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![elijah7](https://avatars.discourse-cdn.com/v4/letter/e/b38774/32.png) [@elijah7](https://forum.cursor.com/u/elijah7)\
**Post date:** [September 5, 2026, 2:12pm UTC](https://forum.cursor.com/t/my-machines-remote-control-route-localhost-streamablehttp-mcp-via-the-worker-not-cursor-cloud-backend/170701/1 "2026-09-05T14:12:17Z")

</div>

### Feature request for product/service

Cloud Agent (GitHub, Slack, Linear,…)

### Describe the request

## Summary

When a Cloud Agent / Remote Control session runs on **My Machines** , local privacy MCP servers that listen on `127.0.0.1` (streamableHttp) are unreachable, because HTTP MCP is dialed from Cursor’s cloud backend. The worker can already edit files and run shell on the host, but cannot use the host’s loopback MCP.

## Repro

1. On a Mac, run a local MCP on `http://127.0.0.1:14242/mcp/` (example: Nowledge Mem).
2. Configure it in `~/.cursor/mcp.json` as `type: streamableHttp` → `http://127.0.0.1:14242/...`.
3. Desktop Agent on that Mac: MCP tools appear and work.
4. Start a Cloud Agent / phone Remote Control session targeting the same machine as a private worker.
5. The agent can read/write the workspace and run shell on the Mac, but the localhost MCP tools are **absent** from the tool catalog.

## Expected

For My Machines / self-hosted workers, streamableHttp URLs that target `127.0.0.1` / `localhost` should be connected **from the worker process on that machine** (same trust boundary as stdio MCP on the worker), not from Cursor’s cloud backend.

Alternatively (weaker): clearly document that local HTTP privacy MCPs are unsupported on My Machines, and that only:

- dashboard-registered **stdio** MCPs (run on worker), or
- publicly reachable HTTPS MCPs (dialed from Cursor backend)

are supported — so users don’t try to “just Remote Control” a localhost Mem/KG.

## Why this matters

Many personal tools intentionally bind to loopback only (memory graphs, local DBs, credential brokers). Asking users to publish those on a public HTTPS endpoint just to use phone Remote Control is the harmful workaround. Stdio is a partial escape hatch, but hosts that already ship streamableHttp-on-localhost (common MCP pattern) still break.

Staff have already clarified elsewhere that:

- My Machines does not read host `~/.cursor/mcp.json` by itself (dashboard / session MCP config).
- **stdio** MCPs run on the worker; **HTTP** MCPs are handled by Cursor’s backend.

This request is specifically about the localhost HTTP case under that model: please either **proxy loopback HTTP MCP through the worker** , or document the limitation prominently for Remote Control / My Machines.

## Related

- Forum: “My Machines Cloud Agent worker does not load MCP servers from the host’s local Cursor MCP config” (staff: HTTP from backend, stdio on worker)
- Companion product issue (Nowledge Mem docs/stdio ask): [Cursor Remote Control / Cloud Agent (My Machines) cannot reach localhost MCP (127.0.0.1:14242) · Issue #579 · nowledge-co/community · GitHub](https://github.com/nowledge-co/community/issues/579)

## Non-goal

I am not asking Cursor to scrape arbitrary host `mcp.json` into every cloud session. The ask is narrower: when a My Machines session is already executing on machine X, loopback MCP on X should be reachable without exposing it to the public internet.

### Operating System (if it applies)

MacOS

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [October 18, 2026, 8:06am UTC](https://forum.cursor.com/t/my-machines-remote-control-route-localhost-streamablehttp-mcp-via-the-worker-not-cursor-cloud-backend/170701/5 "2026-10-18T08:06:28Z")

</div>

Hey, thanks for the detailed feature request. You described the model correctly: with My Machines command stdio, MCP servers start on your machine, while HTTP MCP connections are made from Cursor, so a server on `127.0.0.1` isn’t reachable this way right now. This is intended behavior for self-hosted workers, and the transport table in the My Machines docs covers it.

You can still use a loopback server without exposing it publicly. Register it in the Cloud Agents dashboard as a command server that wraps the HTTP endpoint, for example:

```json
{
  "mcpServers": {
    "nowledge-mem": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://127.0.0.1:14242/mcp/", "--allow-http"]
    }
  }
}

```

This process runs on your Mac and calls the loopback locally, so nothing is exposed externally. Enable it for the session when you start the agent, and the tools should show up in the catalog.

A couple practical notes: make sure the worker has a recent CLI, and that the entry is valid. If there’s a config error, the server can get dropped silently with no warning. You can confirm it loaded in the worker logs by looking for the line `Dynamically loaded MCP server for session`.

We’ve heard the request for worker-side HTTP MCP from others too, and I passed it to the team. No timeline yet, but the wrapper above should unblock your setup right now. Let me know how it goes.