Why we built XenMCP 🔌
TL;DR 🍿
We wanted Claude to look at our own systems: a MongoDB on a VPS, Grafana logs, a Docker host, a Salesforce on the free plan.
MCP makes that possible. Everything around it (sign-in, revoking access, read-only, a log of who called what) is left to you. 🤷
XenMCP is that missing part: per-person sign-in instead of shared keys, read-only by default, every call in a journal, sandboxes in Germany 🇩🇪.
On day one its open-source Docker agent found a crash-looping backend on my own server. Two questions, from my phone. 📱
🚀 The beta is open today. Free, limited places: sign up, confirm your email, and the invitation lands within a minute. 👉 xenmcp.com
📋 The crime scene: copy, paste, explain, repeat
I ask Claude about my systems all day. Why did this container restart at night? What's in the logs before the crash? How many orders came in yesterday?
And every time it was the same routine:
📋 copy the logs into the chat;
🧹 cut out anything that looks like a password;
🗣️ explain what the table is, what the service does;
🔁 repeat tomorrow.
MCP (the Model Context Protocol) was supposed to end this. Technically, it does: there are MCP servers for MongoDB, PostgreSQL, Grafana, Redis, almost anything. The problem is everything around them. 🧱
🧱 The three walls
1. 💸 The vendor's MCP is on a plan I don't have
I wanted Claude to look at my Salesforce. Salesforce has hosted MCP. On Enterprise. I'm on the free plan. Same story with a lot of business software: the API is there, the MCP is a price tier away.
2. 🏠 My data lives on my own servers
My MongoDB runs on a VPS. My logs sit in a self-hosted Grafana with Loki. A vendor's hosted MCP doesn't help at all here: Atlas has one, my VPS doesn't. What I wanted was simple: allow one IP address in the firewall, hand over a read-only user, and let Claude look. Not "install this on your laptop". Not "open your database to the internet". 🙅
3. 🛠️ Running MCP yourself is a second job
The open-source servers are good. But most are programs you start, secure and update yourself. For Claude on the web or on the phone they need a stable HTTPS address with sign-in. Many only speak stdio. Some have no read-only mode at all. And then the boring questions:
👥 who in my team may use it?
🚪 how do I take that access away when someone leaves?
🕵️ who called what, and when?
An API key in a URL that half the team has copied somewhere is not an answer. 🙈
🥊 The contenders
| Vendor's hosted MCP | Open-source MCP, self-run | XenMCP | |
|---|---|---|---|
| Works with your own server | ❌ their cloud only | ✅ | ✅ one IP to allow |
| Free plan | 😬 often Enterprise only | ✅ | ✅ in beta |
| Per-person sign-in, revoke in one click | 🤏 depends | ❌ build it yourself | ✅ OAuth |
| Read-only | 🤏 depends | 🤏 some servers only | ✅ by default |
| Log of every call | 🤏 depends | ❌ | ✅ |
| Works in Claude on web and phone | ✅ | 😬 needs HTTPS + auth | ✅ |
| Your time | ✅ none | ❌ a lot | ✅ a form in the panel |
Winner: obvious, we built it. 🏆 More work for us, less for everyone who connects.
🤓 XenMCP in one paragraph
XenMCP sits between Claude (or Cursor, or VS Code) and your systems. You enter a connection string or a token, XenMCP runs the MCP server in an isolated sandbox and gives you an address like https://yourname.xenmcp.com/mcp. Everyone signs in with their own account. The product isn't the MCP servers themselves, it's running them, sign-in and access control. 🔐
🎁 What you get
1. 📚 A catalog of servers we run for you
MongoDB, PostgreSQL, MySQL/MariaDB, Grafana, Redis, Elasticsearch, Discord and more. Each runs under gVisor 🛡️ on its own network, behind a firewall that lets it reach only your system. Traffic leaves from one fixed IP, so your firewall rule is one line.
2. 🌉 A bridge for MCP servers you already have
Your server wants an API key? XenMCP keeps the key encrypted and puts OAuth in front of it. Your team never sees the key. 🔑
3. 🔐 Per-person sign-in
Everyone connects with their own account. Remove someone from the team and their access stops at once, without rotating a single key.
4. 📒 A journal
Every tool call: who, when, how long, did it work. Not the content: queries and answers pass through, they aren't stored.
5. 👀 Read-only by default
Where an upstream server had no read-only mode or was a poor fit, we wrote our own. The Redis and Elasticsearch servers in the catalog simply have no tool that writes. ✍️❌
🤓 Spoiler: the bugs the sandboxes taught us
🌐 DNS inside gVisor. Docker's built-in resolver (127.0.0.11) doesn't answer inside gVisor sandboxes. Setting Dns doesn't help, Docker still writes 127.0.0.11. Fix: mount our own resolv.conf over it.
🛣️ The default route plot twist. The gateway joins every sandbox network. Docker picks the default route by network name, and xenmcp-sbx-… sorts before xenmcp_default. So with the first sandbox running, traffic to external MCP servers tried to leave through a sandbox network: 502 after 10 seconds. 💥 Fix: GwPriority: -1 for sandbox networks.
Both fixed with tests, not guesses. 🧪
🐳 The Docker agent (open source)
The piece I like most is the smallest one. I have a VPS with a dozen containers and no Grafana. I wanted to ask Claude "what's broken?" without handing anyone the Docker socket. The socket is root on that machine. 😱
So we built the XenMCP Docker agent 🐳: a tiny MIT-licensed container you run next to your others.
📦 lists containers, inspects them;
📜 reads and searches their logs;
📈 shows CPU and memory;
🔔 lists recent events (die, restart, OOM, health).
That's all. It sends Docker only a short allow-list of read requests and refuses everything else before it leaves the process. It never returns environment variables or start arguments, because that's where the passwords live. 🔒 And it's open source precisely so you don't have to trust us on that.
Put it behind your own reverse proxy, the panel gives you a key and a ready docker run line, connect it like any other server. Done. ✅
🚨 What it found on day one
I connected the agent on my own server and asked the obvious: what's running, what's failing?
Thirteen containers, all "up" in the list. The events told a different story: one backend died with exit code 1 and restarted every 40 seconds, for who knows how long. 🔁
One more question, "show me the logs before it dies", and there it was: the database pooler answered tenant not found. The managed Postgres behind it was gone, and nobody had noticed. 🪦
Nothing about that is hard to find. It's just the kind of thing you don't look for until a user complains. With the agent connected it took two questions, from my phone. 📱
🤖 The community server Claude built itself
XenMCP needed a place for beta feedback. We picked Discord. And instead of clicking through its settings for an evening, we did the XenMCP thing: added Discord to the catalog. 🔌
👀 read-only by default: channels, roles, messages, forum posts;
🛠️ read-only off: it may set things up: channels, forums, roles, posts, AutoMod rules, onboarding;
🚫 it never deletes. There's simply no tool for that.
Once the connector was live, Claude got one prompt: here's what the server is for, set it up. It did:
🗂️ categories for start, community, support and beta;
💬 forums for help, bugs and ideas, each with its own tags and a "how to post here" line;
🇩🇪 a German channel;
🏷️ roles for the team, beta testers and Docker agent users;
🧭 onboarding questions, AutoMod, a welcome message and the rules. Rule #1, for a product like this: never paste keys or passwords. 🙅
Nobody clicked through Discord settings for that. We checked the result through the same connector, read-only again. ✅
💬 "When a system has an API but no MCP, the gap between Claude could do this and Claude did this is one connector." — the owner of XenMCP, after the Discord server set itself up
💸 The bill (honestly)
🧪 Beta with limited places. We open places in batches: while there are free ones, the invitation comes within a minute; when they're gone, you wait for the next batch.
🇺🇸 Germany doesn't make Claude European. Results still go to the AI client you connect. What stays in Europe: your credentials and the servers that touch your data, with one small German service instead of one more US platform.
✍️ We write our own servers where upstream ones can't be made read-only. More code to maintain, fewer surprises for you.
🔧 The Docker agent runs on your side. You need a domain and a reverse proxy for it. If it's down, the connector says 502 and only your server can fix it.
🏗️ Spoiler: how it was built
XenMCP is built with Claude Code, step by step: a written plan, a decision log for every choice, nothing merged without my review, every dependency licence checked (MIT, Apache-2.0, BSD, ISC, MPL-2.0 only). It found bugs in its own work along the way and fixed them with tests. The Grafana logs of Xenaxio now reach Claude through XenMCP too. 🍽️ We eat our own cooking.
🏁 Where we are
✅ catalog: MongoDB, PostgreSQL, MySQL/MariaDB, Grafana, Redis, Elasticsearch, Discord and more
✅ your own MCP server with OAuth in front
✅ per-person sign-in, revoke, journal
✅ Docker agent, open source
✅ nightly encrypted backups
✅ open beta: sign up, confirm, invitation within a minute 🚀
⏳ more catalog servers: the votes in #ideas decide which ones
Is Claude still reading your logs through copy-paste? 👀 The beta is open and free. Give it a safe way in:
👉 xenmcp.com · 🐳 github.com/xenMCP/docker-agent · 💬 Discord
Related: Headless or die: if your SaaS doesn't speak MCP, it's already legacy · Corporate data security when using AI tools
Tags: #MCP #Claude #AI Security #Self-hosted #Docker
Comments
Loading comments...