Host-local MCP for external orchestrators (bots / daemons) — REST vs SDK gap

Ideas Feature Requests
, ,
1

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:

5

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.