MCP, not a pasted shell session
Each server exposes clear actions the model can call — register an app, write a file, deploy, update DNS. The assistant works through those tools instead of free-form terminal access.
Project
MCP servers that drive development.
I built six Model Context Protocol (MCP) servers on my VPS so an AI assistant can do real development work: edit code, commit, build, deploy, and put HTTPS in front of the result.
This page is one of the apps those tools deploy.
What this shows
For a recruiter scanning quickly: I can design and run MCP tools that actually ship software.
End-to-end development path
From a request in chat through git, container build, and a public URL. The same path is used when this site is updated.
Rules that keep deploys honest
Failed push or failed build stops the run. Products stay in their own repos and containers. Lab experiments do not become production apps by accident.
The six MCP servers
Running on the host. These are the tools the assistant uses to drive development.
host-control
Git, health checks, deploy hooks, and probes against the host.
docker-apps
App registry, file writes, image builds, and container deploys.
caddy-proxy
HTTPS and routing so each app is reachable on its own domain.
github-ops
Repositories and webhooks so a push can trigger a deploy.
hostinger-dns
DNS records so hostnames resolve before certificates issue.
wireguard-vpn
Private access to the host when public entry is not the right path.
How a change ships
Same sequence used for updates to this page.
- 1. RequestChange described in chat.
- 2. MCP toolsAssistant calls the servers above.
- 3. GitCommit and push on main.
- 4. BuildContainer image rebuilt.
- 5. LiveHTTPS serves the new version.
Live apps on this setup
Two products. Separate repos and containers. Same MCP toolchain.
