# Host-local MCP for external orchestrators (bots / daemons) — REST vs SDK gap **URL:** \ **Category:** Feature Requests\ **Tags:** mcp, cursor-sdk, cloud-agents\ **Created:** [June 26, 2026, 7:09pm UTC](https://forum.cursor.com/t/host-local-mcp-for-external-orchestrators-bots-daemons-rest-vs-sdk-gap/164166 "2026-06-26T19:09:20Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![bearaujus](https://avatars.discourse-cdn.com/v4/letter/b/71c47a/32.png) [@bearaujus](https://forum.cursor.com/u/bearaujus)\ **Post date:** [June 26, 2026, 7:09pm UTC](https://forum.cursor.com/t/host-local-mcp-for-external-orchestrators-bots-daemons-rest-vs-sdk-gap/164166/1 "2026-06-26T19:09:20Z")
Hi Cursor team and community, I’m working on **open-source assistant infrastructure** — think bot/daemon integrations with per-session workspaces on the host, plus built-in MCP tools (workspace I/O, session memory, optional VCS). Users can plug in different LLM providers; OpenAI-style tool calling works well there because tools run on the **same machine** as the orchestrator and context stays on disk. I’m trying to offer **Cursor** as a provider too, but the integration path feels much weaker for this use case unless we embed large file excerpts in every prompt. I’d love guidance or product support for a cleaner pattern. ### What we’re trying to do - Each session gets an isolated workspace directory on the orchestrator host (materialized knowledge, attachments, memory, manifests). - Each turn: attach MCP tool definitions and let the model loop until it has a final answer. - **Goal:** context on disk + live tool use — **not** megabytes of inlined files in the prompt. ### What works with OpenAI-style providers Standard tool-calling loop: tools execute in-process on the host. No prompt stuffing. ### What we’ve hit with Cursor **Cloud Agents API (`POST /v1/agents`, no-repo agents)** We can create an agent per turn, send prompt + images, poll, archive. That works for plain Q&A, but for workspace-heavy turns we end up **embedding file excerpts** in the prompt and telling the model it has no live filesystem — otherwise answers are blind to anything not inlined. We looked at `mcpServers` on the API docs: - **stdio MCP** runs inside Cursor’s cloud VM, not on our host — it can’t see our session workspaces. - **HTTP MCP** could work only if we expose a public endpoint per session/turn. That’s a big shift for local-first / self-hosted open-source deployments. **Cursor SDK local runtime (`@cursor/sdk` / `cursor-sdk`)** This is closer to what we need: `local.cwd` on our machine, MCP via stdio or `local.customTools`. But for our stack it still means: - No Go SDK — we’d need a Node (22.13+) or Python sidecar next to a Go daemon. - Integration is SDK-shaped, not the simple REST flow we use for verify + one-shot turns. - Local agents include powerful built-in tools (shell, edit, write, grep) by default in headless mode; we intentionally expose a **narrow MCP surface** — locking that down via hooks/sandbox is extra work. - `local.customTools` is **local-only** ; moving the same wiring to cloud means rebuilding as HTTP MCP anyway. Community MCP projects around Cursor mostly expose **Cursor’s API as tools for other assistants** — the opposite direction from what we need (our tools → Cursor agent). ### Pain points (in priority order) 1. **Host-local MCP for API consumers** — daemons/bots with on-host workspaces, not cloned GitHub repos. We need a supported way for a Cursor agent to use MCP where tools run **next to the workspace** without embedding files in the prompt. 2. **REST vs SDK parity** — SDK documents `mcpServers`, `local.customTools`, resume, etc. REST `/v1/agents` feels optimized for repo-based cloud agents. Is there a documented pattern for **no-repo + tools**? Or a plan to bring tool/MCP ergonomics to REST? 3. **External tool executor** — many orchestrators already own MCP and want: system + messages + tools → loop until done (like OpenAI function calling). A thinner mode, or a **client-executed tool** / loopback MCP tunnel, would help frameworks that aren’t IDE/repo-centric. 4. **Headless safety** — for server/bot embeddings, an explicit **MCP-only** or tools-allowlist mode (without shipping `.cursor/hooks.json` into every session workspace) would help. 5. **Multi-turn** — creating/archiving a cloud agent every turn is heavy. Local SDK has `Agent.resume`; clearer API guidance for long-lived agents tied to an external session id would help. ### What would help us most 1. Documented pattern: **external orchestrator + on-host workspace + MCP** (not repo clone, not prompt embedding). 2. Caller-side tool execution — agent emits tool calls; **client runs them** and returns results (or official loopback MCP to the host). 3. REST support for `mcpServers` on no-repo agents with clear semantics. 4. Headless config to disable built-in shell/edit when only custom MCP should run. 5. Any roadmap signal on language-neutral clients (e.g. OpenAPI) and long-term support for no-repo cloud agents. ### Why it matters People already save Cursor User API keys (`crsr_`) in open-source bot integrations. Today they often get a worse experience than OpenAI users on the same product — not because Cursor’s models are weak, but because the **host-local tool path** isn’t first-class for this integration shape. Happy to share repro details, example request shapes, or jump on a call if useful. Related threads I found: - [Cursor SDK feedback and ideas](https://forum.cursor.com/t/cursor-sdk-feedback-and-ideas/159769) - [Cursor SDK in Public Beta](https://forum.cursor.com/t/cursor-sdk-in-public-beta/159285) ---
**Author:** ![Jason\_Luo1](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@Jason\_Luo1](https://forum.cursor.com/u/Jason_Luo1)\ **Post date:** [June 27, 2026, 6:58am UTC](https://forum.cursor.com/t/host-local-mcp-for-external-orchestrators-bots-daemons-rest-vs-sdk-gap/164166/5 "2026-06-27T06:58:09Z")
The host-local part feels like the key distinction here. For external orchestrators, the workspace is not just “context to upload.” It is part of the runtime. Once tools and files live on the caller’s machine, forcing everything through cloud-side MCP or prompt stuffing changes the whole integration model.