Cursor + MCP: letting your editor's agent run real websites

Cursor supports MCP, which means its agent can call tools that a server exposes. Point Cursor at ReDock on localhost:47200 and the agent gains the ability to run real websites — create a local site, start and stop it, author WordPress through Gutenberg blocks, share it, and deploy it — all from inside the editor you’re already coding in. The code and the running site sit behind one connection.

Cursor is good at editing files. MCP is how it stops being blind to what those files are running as. Here’s how to wire the two together.

What MCP adds to Cursor

Out of the box, Cursor’s agent reasons over your codebase and edits files. What it can’t natively do is operate the environment those files run in — start a dev server it can observe, provision a database, log into a WordPress admin. MCP tools fill that gap.

ReDock supplies them. It’s a native macOS app (macOS 12+, Tauri and Rust, not Electron) that hosts your local sites — WordPress, headless WordPress, Astro, Next.js, Node, Bun, PHP, MySQL — each at https://name.test with a locally trusted certificate. Its whole surface is MCP tools on an HTTP port, so Cursor connects by naming the endpoint. No spawned subprocess, no config file to hand-edit. Easy MCP setup explains why that’s zero-config.

Wiring Cursor to ReDock

1. Install and open ReDock. The app and its MCP server come up together — see the install guide.
2. Create a site for the project you’re working on. It’s served at https://name.test; the first-site guide has the steps.
3. Add the MCP server in Cursor, pointing at localhost:47200.
4. Check the tool list. Once Cursor shows ReDock’s tools, its agent can act on the running site.

The full tools list lays out everything the agent inherits.

An editor agent that sees the running site

The payoff is a tighter loop. While you edit code, Cursor’s agent can:

• Run the thing it’s editing. Create a site, start it, stop it — with status derived from the real process, so the agent knows whether its last action actually worked.
• Author WordPress content from real Gutenberg blocks and patterns, and magic-login to wp-admin. See WordPress through MCP.
• Share for review. A Cloudflare tunnel — QuickShare for throwaway links, named redock.xyz subdomains for stable ones — turns local work into a URL a teammate can open.
• Deploy. One-click Cloudflare Workers deploys with custom domains, covered in deploy a website for free.

ReDock also treats n8n and Remotion as first-class local stacks, so a Cursor agent working on automation or video rendering has real runtimes to drive, not stubs. The stacks docs list what’s available.

Sharing state with your other clients

Because ReDock serves over HTTP, Cursor isn’t the only client that can be attached. Claude Desktop can connect to the same localhost:47200 at the same time and see the same sites — the Claude Desktop walkthrough shows that path. You might drive content authoring from one and run the dev loop from Cursor, against a single shared state. MCP over HTTP explained covers why the transport allows this.

No API keys are required for the local agent path — ReDock ships a built-in agent and a local-LLM catalog, and it’s free.

FAQ

Does Cursor run ReDock’s server itself?

No. ReDock runs independently as an app and serves MCP over HTTP. Cursor connects to the existing endpoint rather than launching a subprocess.

Can Cursor’s agent deploy, or only edit locally?

It can deploy. The tool surface includes sharing over Cloudflare tunnels and one-click Cloudflare Workers deploys, so the agent can take a local site to a public URL.

Will connecting Cursor conflict with Claude Desktop?

No. Multiple clients can connect to localhost:47200 at once and share the same sites and state.

Let your editor’s agent run the sites it’s editing — download ReDock.