HTTP/OAuth 2.1 wrapper that exposes delphix/dxi-mcp-server (the official Delphix DCT MCP server, which only speaks stdio) as a remote MCP connector usable from Claude Web/Android — without changing a single line of dxi-mcp-server's source code.
Claude Web/Android --HTTPS/OAuth--> Nginx --> dlpx-mcp-gateway (OAuth + proxy) --> mcp-proxy --stdio--> dxi-mcp-server (vendor, untouched)
See docs/architecture.md for the full design and the reasoning behind it.
Everything is done through a single script, run from this development machine (nothing to install — just bash + ssh/scp):
./mcp-server.shThis opens a menu:
1) Install / reconfigure the server (from scratch)
2) View service status
3) Start services
4) Stop services
5) Update dxi-mcp-server (git pull + restart)
6) Uninstall (remove everything from the server)
0) Exit
The first time you choose 1) Install, the menu asks for the essentials (SSH host/user, domain, Delphix DCT
credentials, gateway admin password) and saves them to deploy/deploy.conf (outside of git) so it won't ask
again. From there, the script itself connects to the CentOS server via SSH and does everything else: installs
prerequisites, clones dxi-mcp-server, configures systemd/Nginx/certbot, and starts the services.
At the end, it prints the URL to register as a Custom Connector in Claude.
You can also call an option directly without the interactive menu: ./mcp-server.sh 2 (view status).
gateway/— the wrapper's source code (Python): OAuth 2.1 Authorization Server + authenticated reverse proxy. It's the only place with custom logic — dxi-mcp-server is never modified.deploy/— everything related to installing/operating the remote server: the scripts that run on this machine (deploy/lib/), the ones that run inside the server (deploy/remote/), and the systemd/Nginx templates (deploy/templates/).mcp-server.sh— single entry point (interactive menu).docs/architecture.md— architecture design and decisions.
Whenever the upstream repository (delphix/dxi-mcp-server) receives updates, choose option 5) Update in the
menu. This runs git pull --ff-only on the vendor clone inside the server and restarts the service — Python
dependencies are automatically resynced by the vendor's own start_mcp_server_uv.sh on every start.
This project was designed with the assumption that the CentOS server is periodically recreated from scratch
(lifespan of a few weeks) and gets a new domain each time. That's why the 1) Install option is idempotent and
can — in fact, should — be run again against any new server, without needing to edit anything other than
deploy/deploy.conf.