How to Deploy a Remote MCP Server on Cloudflare Workers in 2026
The important change since the original version of this guide is transport. For a remote MCP server on Cloudflare Workers, use Streamable HTTP rather than a local stdio transport. New Cloudflare remote MCP deployments expose an HTTP endpoint such as /mcp.
1. Decide whether the server is local or remote
MCP supports local and remote connection patterns. A local client can start a server process and communicate through standard input and output. A Cloudflare Worker is different: it is a remote HTTP service, so the server needs an HTTP transport designed for network connections.
This distinction matters because a server that works as a local stdio process is not automatically a valid remote Worker deployment.
2. Start with a small tool surface
Do not expose an entire business API simply because MCP makes tool calling possible. Start with one or two narrowly defined tools that map to real user outcomes. For example, a read-only customer lookup or a controlled document search is easier to secure, test and understand than dozens of unrestricted actions.
Each tool should have a clear name, a precise description, validated inputs and predictable output. If an action can change data, make the permission boundary explicit.
3. Use Cloudflare's current remote MCP pattern
Cloudflare's current Agents guidance uses its MCP server helpers to handle the remote protocol on Workers. For a new stateless server, follow the current createMcpHandler() pattern in the official Cloudflare guide rather than copying an old stdio or deprecated SSE example.
The public endpoint for a new connection should normally be an MCP route such as https://your-worker.example/mcp. Keep the exact SDK and package versions pinned in your project because the MCP ecosystem is moving quickly.
4. Add authentication before sensitive tools
A demo server that returns harmless sample data can be public. A server that touches customer information, internal documents, cloud accounts or write-capable APIs should not be anonymous by default.
Use the authentication approach supported by your client and deployment architecture, scope credentials to the minimum required permissions, and keep secrets in the platform's secret store rather than in source code.
5. Treat HTTP security as part of MCP security
Remote MCP is still an HTTP service. Validate the request origin where required, restrict access, validate every tool input, rate-limit abusive traffic where appropriate, and avoid returning internal error details to untrusted callers.
For tools that can perform consequential actions, add an explicit approval step instead of relying on the model to infer whether an action is safe.
6. Test the protocol before testing the AI
First prove that the MCP endpoint can initialize correctly, list tools and execute a known test call with the expected schema. Only then connect an AI client and test whether it chooses and uses the tool correctly.
This separation makes failures much easier to diagnose: protocol problems, authentication problems, tool implementation problems and model-behaviour problems should not be mixed together.
7. Deploy with observability and rollback
Before production use, capture enough logs to understand failed requests without recording sensitive payloads unnecessarily. Keep a known-good deployment or rollback path, and re-run your tool tests whenever the MCP SDK, tool descriptions, authentication or Worker configuration changes.
Common mistake: copying an old transport example
MCP transport guidance has changed significantly. Older articles may show remote SSE patterns or local stdio code in contexts where Streamable HTTP is now the correct choice. Check the current protocol and hosting-provider documentation before copying an example into production.