Local MCP vs remote MCP: where should your agent's hands live?
A local MCP server runs on your machine and reaches your files and sites; a remote one runs elsewhere and serves a shared service. The reach decides which you want.
A local MCP server runs on your own machine and can reach the things only your machine has — your filesystem, your local sites, your ports. A remote MCP server runs somewhere else and exposes a shared, hosted service to whoever connects. The right choice comes down to reach: if the agent needs to touch your machine, the server has to be on it. ReDock is a local MCP server for exactly that reason — it runs your websites, so it lives where the websites live.
Both kinds are valid, and many setups use both. The question is which job you’re handing the agent.
What a local MCP server reaches
“Local” isn’t about speed; it’s about access. A server on your machine can do things no remote service can:
- Touch your filesystem — read and write real project files.
- Run and control local processes — start a dev server, a database, a site.
- Bind local ports — serve
https://name.testwith a locally trusted certificate.
This is ReDock’s whole shape. It’s a native macOS app (macOS 12+, Tauri and Rust, not Electron) that hosts local sites — WordPress, headless WordPress, Astro, Next.js, Node, Bun, PHP, MySQL — and exposes its surface as MCP tools on localhost:47200. A remote server simply can’t run a site that lives on your laptop. If the agent’s job is to operate your local environment, the server belongs there. Easy MCP setup shows how little that costs to stand up.
What a remote MCP server is good for
Remote servers shine when the capability is inherently shared or hosted: a SaaS product’s API, a team database, a service that should be the same for everyone who connects. There’s no machine-local resource involved, so putting it on your laptop would only make it less available. Remote is the natural home for those.
The mistake is using one where the other fits — trying to reach your local files through a remote server (it can’t) or hosting a genuinely local capability remotely (why would you). Match the server’s location to where the resource actually lives.
Local doesn’t mean exposed
A common worry: if the server is on my machine and speaks HTTP, is my machine exposed? No. localhost:47200 binds locally — it’s reachable only from your machine. The HTTP transport is about letting multiple local clients share one server, not about opening a door to the internet. MCP over HTTP explained covers that transport in detail.
When you do want the outside world to see something, ReDock treats that as a separate, deliberate act — sharing a site over a Cloudflare tunnel (QuickShare or a named redock.xyz subdomain), or a one-click deploy to Cloudflare Workers. Exposing a site is a choice you make per site; the MCP port itself stays local. Deploy a website for free walks through going public on purpose.
Why local + honest state is a good pairing
A local server that controls real processes needs to tell the truth about them. ReDock maps every status from actual process state — running, stopped, shared — rather than from “we sent the command.” For an agent operating your machine, that honesty is what makes recovery possible instead of hallucinated. The MCP docs document the surface, and the built-in agent docs show it in use — with no API keys required, thanks to the local-LLM catalog.
Because it’s local and HTTP, the same server backs every client at once. Claude Desktop and Cursor can both connect to localhost:47200 and share state — see the Claude Desktop and Cursor walkthroughs.
FAQ
Is a local MCP server slower or less capable than a remote one?
Neither, for local work — it’s more capable, because it can reach your files, processes, and ports. A remote server simply can’t touch those.
Does running a local HTTP MCP server expose my machine to the internet?
No. A server bound to localhost (like ReDock on localhost:47200) is reachable only from your machine. Exposing a site is a separate, deliberate step via Cloudflare tunnels.
Can I use local and remote MCP servers together?
Yes. Point your client at both — a local server for your machine’s resources, remote servers for hosted services. Match each to where the resource lives.
ReDock puts your local web stack behind a local MCP endpoint your agents can operate — download ReDock.