From a local server to a working connector
Most MCP servers run locally over stdio, so they never reach the Claude app on a phone or the rest of the team. XenMCP wraps them behind Streamable HTTP and OAuth without rewriting the server.

MCP hosting from Germany
Most MCP servers run locally over stdio. To use one in the Claude app on a phone, share it with a team or keep it running, someone has to move it to Streamable HTTP, add OAuth, host it and watch it. For most people that is where it stops.
XenMCP does that part. Pick a server from the catalog and enter your credentials, or connect your own, and you get a fixed address at name.xenmcp.com with OAuth 2.1 that you add once as a connector in Claude, Cursor, VS Code or any other MCP client.
Gateway, sandboxes and database run on servers in Germany, with no US provider's proxy in front of them, and a DPA for companies. The results of a query still go to whichever AI client you use; to keep the whole chain in the EU, use a European one such as Le Chat, the xenaxio assistant or your own model.
A product of xenaxio with its own name, domain and infrastructure. The landing page and waitlist are up; the closed beta starts with the catalog and the OAuth bridge.
Most MCP servers run locally over stdio, so they never reach the Claude app on a phone or the rest of the team. XenMCP wraps them behind Streamable HTTP and OAuth without rewriting the server.
For a remote server that only accepts an API key, the key stays encrypted with XenMCP and everyone signs in as themselves. Access is revoked per person without rotating the key, and the log shows who called which tool.
Every MCP server runs isolated in gVisor with its own CPU and memory limits, outbound traffic only to the domains it needs, and a fixed outbound IP you can allow in your firewall.
XenMCP records which tool was called and when, never the requests or the results. Credentials are encrypted with AES-256-GCM and never shown again.
Comments
Loading comments...