Imagine piecing together a digital puzzle where every piece clicks into place with just the right mix of tech and creativity. That’s exactly what we’re doing today as we dive into deploying a remote MCP (Multi-Cloud Platform) server using Cloudflare’s powerful tools—think Durable Objects, Workers, and the shiny new WorkOS Offkit for authentication. This isn’t just about code; it’s about crafting something functional, secure, and maybe even a little fun. So, grab a coffee, settle in, and let’s walk through this process together, step by step, in a way that’s easy to follow and light on the jargon overload.
Why Cloudflare and WorkOS?
Before we jump into the how-to, let’s talk about why this combo is worth your time. Cloudflare is like the Swiss Army knife of the internet—fast, reliable, and packed with tools to make your life easier. Their Workers platform lets you run code at the edge, meaning your app responds lightning-fast no matter where your users are. Add in Durable Objects for stateful storage and you’ve got a robust setup for building something like an MCP server.
Now, WorkOS Offkit? That’s the authentication magic. It handles user logins securely without you having to reinvent the wheel. Together, they’re a dream team for deploying a server that’s not only powerful but also locked down tight with proper auth. And the best part? Cloudflare makes it ridiculously easy to get started with a one-click deploy button. So, let’s hit that button and see where it takes us.
Step 1: Setting Up the Foundation
Picture this: you’re starting a new project, and Cloudflare hands you a toolbox filled with everything you need. That’s what happens when you click the “Deploy to Cloudflare” button. It’s like opening a gift box of pre-configured settings—stock options for your Worker, a GitHub repository ready to go, and a subdomain to call your own. But don’t worry, you’re not locked in. Want to tweak things? Go wild. This is your playground.
First, we initialize our repository on GitHub. It’s as simple as creating a new repo and letting Cloudflare do the heavy lifting. Once that’s done, we clone the repo to our local machine. Here’s what that looks like in your terminal:
git clone <your-repo-url>
cd <your-repo-name>Next, we install dependencies. If you’re using Node.js, this is just a quick:
npm installNow, we build the application. Cloudflare’s setup includes a build script, so running:
npm run buildgets everything compiled and ready to roll. Once the build is done, we deploy to Cloudflare’s edge network with:
npm run deployAt this point, you should have a shiny new app live at a subdomain Cloudflare sets up for you—something like your-app.workers.dev. Exciting, right? But hold up. If you visit that URL now, you might see an “Internal Server Error.” Don’t panic—it’s just a sign we’ve got a little more work to do.
Step 2: Tackling the Internal Server Error
In this case, our internal server error is likely tied to missing authentication keys. Our MCP server needs to talk to WorkOS, and for that, it needs two things: a WorkOS Client ID and a WorkOS Client Secret.
Let’s grab those from the WorkOS dashboard. Head over to your WorkOS account (if you don’t have one, signing up is quick and free for testing). In the dashboard, you’ll find your Client ID and Client Secret under your project settings. Copy both, and let’s head back to Cloudflare.
In your Cloudflare Worker dashboard, go to Settings > Variables and Secrets. Here’s where we store our keys:
- WorkOS Client ID: This isn’t a secret, so we can add it as a plain text variable. Name it WORKOS_CLIENT_ID and paste the ID.
- WorkOS Client Secret: This one’s sensitive, so we encrypt it. Add a new secret named WORKOS_CLIENT_SECRET and paste the secret as the value.
Save both, but don’t deploy just yet. We want to make sure everything’s in place first. Once both keys are added, hit the deploy button. Cloudflare will push the updated Worker to the edge, and we can check our subdomain again.
Step 3: Dealing with New Errors (Yes, More!)
Refresh your subdomain, and… oops, a 404 Not Found error. Don’t worry—this is progress! The 404 means our Worker is live, but the route we’re trying to hit isn’t quite right. Our MCP server uses an SSE (Server-Sent Events) endpoint, which is likely at a specific path like /sse. Check your project’s README or Cloudflare’s docs for the exact route.
Try visiting your-app.workers.dev/sse. Now you might see an “Invalid Token” error. Believe it or not, this is good news. It means our Worker is talking to WorkOS, and the authentication setup is mostly correct. The invalid token error is just WorkOS saying, “Hey, I don’t recognize this request yet.”
Step 4: Testing Authentication with Workers AI Playground
To test our MCP server’s authentication, let’s use Cloudflare’s Workers AI Playground. It’s a handy tool for interacting with your Worker without writing a ton of frontend code. Navigate to the playground in your Cloudflare dashboard, and add a new MCP server using your subdomain (e.g., your-app.workers.dev).
Hit Connect, and you’ll be redirected to WorkOS’s Offkit login page. But—uh-oh—another error: “Invalid Redirect URI.” This happens because WorkOS needs to know where to send users after they log in, and we haven’t told it about our Cloudflare subdomain yet.
Back in the WorkOS dashboard, go to Redirects and find the Sign-in Callback section. Click Edit Redirect URIs and add your Cloudflare subdomain with the callback route (something like your-app.workers.dev/callback). Save, then head back to the Workers AI Playground and try connecting again.
This time, you should see a login prompt. Enter your user credentials (or use a test account if you’re in dev mode), and boom—you’re authenticated! You’re now connected to your MCP server.
Step 5: Playing with MCP Tools
Out of the box, our MCP server comes with a simple tool: it can add two numbers. Not exactly world-changing, but it’s a great way to test the setup. In the Workers AI Playground, try a request like:
What is 42 plus 42?
The playground will show the MCP server processing the request, using the add tool, and returning:
The answer to 42 plus 42 is 84.
Pretty cool, right? The server took your input, ran it through the tool, and gave you a clear response. This is the power of MCP—handling tasks in a structured, extensible way.
Step 6: Taking It Further with Cursor Integration
Testing in the playground is fun, but let’s make this server truly useful by integrating it with a real tool: the Cursor editor. Cursor is a code editor with AI features, and it supports custom MCP servers for advanced workflows.
Open Cursor and go to Settings > MCP. Here, you can add a new global MCP server by editing a JSON config file. It looks something like this:
{
"name": "My MCP Server",
"url": "your-app.workers.dev",
"command": "mcp-run",
"args": ["--auth", "workos"]
}Save the file, and Cursor will prompt you to authenticate using WorkOS Offkit. Log in, and your MCP server is now part of your Cursor workflow. You can use it to run tools, process code, or even automate tasks—all from your editor.
Step 7: Exploring Cloudflare’s Resources
If you hit any snags, Cloudflare’s got your back. Their AI repository on GitHub has a demo section for remote MCP servers, complete with guides on setup, troubleshooting, and advanced arguments. Look for the remote-mcp-github-oauth folder—it’s packed with tips to keep you moving.
For example, if your authentication fails, double-check your WorkOS Redirect URIs. If your Worker crashes, peek at the logs in Cloudflare’s dashboard. And if you’re curious about what else MCP can do, the docs list additional tools and integrations you can add.
Step 8: What’s Next?
So, you’ve got a remote MCP server running on Cloudflare, authenticated with WorkOS, and integrated with Cursor. What’s next? The possibilities are endless. You could:
- Add more tools to your MCP server, like text processing or API calls.
- Set up role-based permissions to control who can use which tools.
- Scale your Worker to handle more traffic using Cloudflare’s global network.
- Experiment with Durable Objects to store state, like user sessions or tool outputs.
The beauty of this setup is its flexibility. Cloudflare’s edge network makes it fast, WorkOS keeps it secure, and MCP’s tool-based architecture lets you build exactly what you need.
A Few Tips for the Road
Before we wrap up, here are some nuggets of wisdom to keep in your back pocket:
- Check Your Variables: If your Worker isn’t behaving, make sure your Client ID and Secret are correctly set in Cloudflare’s dashboard.
- Read the README: Your project’s README is a goldmine of setup instructions and troubleshooting steps.
- Test Locally: You can clone your repo and run the Worker locally with wrangler dev to catch issues before deploying.
- Stay Curious: Cloudflare and WorkOS are always adding new features. Keep an eye on their blogs for updates that could supercharge your setup.
Wrapping Up
Building a remote MCP server with Cloudflare and WorkOS is like assembling a LEGO set—it’s a little fiddly at first, but once the pieces snap together, you’ve got something awesome. From deploying with a single click to authenticating users and integrating with tools like Cursor, this process shows how modern platforms make powerful tech accessible to everyone.
So, what do you think? Ready to spin up your own MCP server and see what it can do? The tools are in your hands—go build something amazing.
0 comments:
Post a Comment