The MCP tools list every web developer should know

MCP tools are named, self-describing functions that an AI agent can call — each one has a description and a JSON Schema for its inputs, so the model knows what it does and how to call it. For local web development, the useful set clusters into a few jobs: standing sites up, running them, authoring content, sharing, and deploying. ReDock exposes all of these at localhost:47200 for any MCP client.

This is a map of the tools that matter, grouped by what you’d actually ask an agent to do. If you’re new to the protocol itself, what is MCP is the primer.

Site lifecycle: create, start, stop

The foundation is standing up a real local site and controlling it.

• Create a site. Spin up WordPress, headless WordPress, Astro, Next.js, Node, Bun, PHP, or MySQL — each served at https://name.test with a locally trusted certificate.
• Start and stop. Bring a site up or take it down. Status reflects the real process, not a guess.
• List sites. Enumerate what exists so the agent picks the right target instead of assuming one.

That last point matters more than it looks. An agent that can list sites and read real status recovers from surprises; one that assumes state hallucinates through them. ReDock’s honest-state rule — UI and tool results mapped from actual process state — is what makes lifecycle tools safe to hand to an agent. Your first site shows the flow end to end.

Authoring WordPress the right way

WordPress is the first-class case, and the authoring tools go through real Gutenberg internals rather than pasting HTML:

• Author with blocks and patterns. Content is built from actual core/* blocks and registered patterns, so it renders and edits like anything a human made in the editor.
• Magic-login to wp-admin. Jump into the admin without hunting for a password.
• Read and verify. Pull rendered output back to confirm a change actually took.

Because the blocks are real, an agent’s post opens cleanly in the editor afterward — no “why is this a raw HTML block” cleanup. WordPress through MCP goes deeper on this, and the built-in agent uses these tools directly.

Sharing and deploying

Local work usually needs to leave the machine eventually. Two groups of tools cover that:

• Share over Cloudflare tunnels. QuickShare gives you a throwaway public URL; named redock.xyz subdomains give you stable ones. Nothing is exposed until you ask.
• Deploy to Cloudflare Workers. One-click edge deploys, with custom domains when you want them.

Sharing and deploying are separate, deliberate acts — the MCP port itself stays bound to localhost. Deploy a website for free walks through the deploy path.

The stacks behind the tools

The tools are only as useful as the runtimes they drive. ReDock treats several stacks as first-class local citizens: WordPress and headless WordPress, Astro and Next.js for the JavaScript side, Node and Bun as runtimes, PHP and MySQL, plus n8n and Remotion as first-class local stacks. The stacks docs list what’s supported.

There’s also a built-in agent and a local-LLM catalog, so you can drive these tools without wiring up external API keys. And because the server speaks HTTP, the same tool set is available to every connected client at once — see MCP over HTTP explained for why that transport choice matters.

FAQ

What makes an MCP tool different from a normal function?

Self-description. Each tool ships a name, a human-readable description, and a JSON Schema for its inputs, so an agent can discover and call it without hardcoded knowledge. MCP vs plain APIs unpacks the distinction.

Do I need to memorize these tool names?

No. The agent discovers them at connect time and picks the right one. You describe the goal in plain language.

Are the tools the same across clients?

Yes. ReDock serves one tool set at localhost:47200, so Claude Desktop, Claude Code, and Cursor all see the same verbs and the same sites.

Point your agent at ReDock’s endpoint and it inherits this whole tool set — download ReDock.