I was catching up with a friend who is CTO at a company with 80+ engineers. Nine-figure ARR. Serious technical org.
I mentioned how I distribute custom MCP servers to my team — deploy once on Cloudflare Workers, add the URL to our org settings, and everyone connects with Google sign-in. No local setup.
He stopped me.
“Wait — you can do that?”
He’d never heard of this pattern. Immediately shared it with his team.
If a CTO at that scale wasn’t yet aware of it, it’s probably worth sharing.
Why custom MCPs
Most SaaS tools either don’t have an official MCP or ship one that covers a fraction of their API. No multi-account support. No domain-specific logic. No awareness of how your team actually uses the tool.
But the bigger opportunity isn’t patching gaps in official integrations — it’s connecting the systems no official MCP will ever touch.
Your data, your tools
- Internal systems — databases, knowledge bases, CRMs, the dashboards your team built in-house
- Cross-system queries — pull from your ticketing system and your analytics platform in a single ask, instead of two tabs and a spreadsheet
- Domain logic — opinionated defaults, business rules, guardrails that prevent mistakes before they happen
Not just for engineers
The people who benefit most aren’t developers. It’s the PM who can ask Claude a question and get an answer grounded in production data without learning SQL. It’s the ops lead who can check inventory or revenue without waiting on a report.
You’re not just giving your team new tools — you’re giving them direct access to the information they need to make decisions.
So you build your own. You expose exactly the endpoints your team needs, with your business logic baked in. That’s the easy part.
The hard part is getting it to everyone else. Securely.
The problem with local MCPs
The default MCP setup is local — install Node, clone a repo, configure API keys, run a process. Fine if you’re a developer working solo.
Now try distributing that to a team:
- Each person needs the right runtime installed
- Each person needs API credentials on their machine — real keys to production services, sitting in plaintext config files on every laptop
- Non-technical team members can’t do any of it
Most teams just don’t bother. The MCPs stay on one person’s machine.
Remote MCP servers fix this
The idea is simple: run your MCP server on Cloudflare Workers instead of locally. It’s a URL, not a process.
An admin deploys the server once. Adds the connector URL to the organization’s Claude settings. That’s it.
Every team member — across Claude Desktop, Claude Code, and Claude.ai — sees the new integration automatically. They click Connect, sign in with their Google account, and they’re using it. No installs. No credentials on their machine. No terminal commands.
Security built in
A remote MCP server without authentication is an open door — anyone who finds the URL can call your tools and burn through your API keys. Google OAuth locks it down:
- Only people in your Google Workspace domain can authenticate
- API keys live in Cloudflare secrets, server-side, never on client machines
- No credentials in config files
- No keys to rotate across every laptop when someone leaves
Team members sign in once with Google. The token refreshes automatically. They forget about it.
What the setup looks like
From the admin side:
- Build the MCP server — define your tools, connect to whatever API you need
- Deploy to Cloudflare Workers
- Add the connector URL in your org’s Claude settings
From the team member side:
- Open Claude — the new integration is already there
- Click Connect
- Sign in with Google
- Done
That’s the entire experience. No documentation to read, no setup guide to follow, no Slack thread asking why it’s not working.
What I built
I use this pattern enough that I turned it into a plugin for Claude Code. It’s called cf-mcp — it scaffolds the entire project. Templates for the Worker, the OAuth flow, the MCP agent, the API client. A skill that walks Claude through setup, implementation, deployment, and testing end to end.
If you want to try it:
- Plugin:
/plugin install cf-mcp@adamlevoy-plugins - Marketplace:
/plugin marketplace add adamlevoy/claude-plugins - Source: github.com/adamlevoy/claude-plugins/tree/main/plugins/cf-mcp
The pattern works. My team uses it daily. And the gap between “I built a cool MCP” and “my whole team has access” is a single deploy and a URL.