Show HN: An MCP server for Devops automation

6 points by czhu12 46 days ago | 2 comments

I’ve been building Canine for about 2 years now, and have slowly grown it to about ~1000 developers using it for deploying all sorts of apps / projects / etc. Amazingly, the whole thing is still able to run on a single 48GB Hetzner VPS. Think of it basically like Coolify, for Kubernetes. I previously posted about it here: https://news.ycombinator.com/item?id=44292103

Recently, we added MCP capabilities to canine, and I was shocked how well it worked. It basically is able to create services, cron jobs, databases, get the logs for these and redeploy. See it here: https://canine.sh/model-context-protocol. The real killer feature has been an MCP tool to be able to download a temporary kubeconfig, which lets Claude then breakout and get the full Kubernetes API to automate pretty much anything. A little scary how competent Claude can be here.

When we paired this with Claude code running locally, you’re basically able to have a fully autonomous system vibe code, deploy, wait, and test in staging (by querying APIs, no browser skills yet), automatically fix bugs, repush, etc.

Best practices in this area haven’t quite been established and I know this community has a somewhat nervous relationship with AI tools. The way we have it set up is basically to only allow access on staging servers, and disable entirely on production, for fear of things going wrong. MCP is opt in on canine at the moment.

The implementation was pretty easy. We just took our API and basically wrapped an MCP OAuth authentication around it where all the GET endpoints became resources and all the POST / PUT / DELETE endpoints became tools. Digging through other MCP implementations, it seems the actual documentation is quite out of date. The MCP documentation recommends using Prompt objects to guide the LLM’s, but most implementations I’ve seen out there actually use skills, which have to be installed.

Anyways, happy to share whatever, it was a cool bit of project, just now seeing how people will use this.

czhu12 46 days ago |

The code for the MCP implementation is here: https://github.com/CanineHQ/canine/blob/main/app/controllers... for anyone curious.

Sticking with standard Kubernetes API patterns, the model has a pretty good intuition about how to traverse and debug applications, fetch logs, scale services, debug networking, etc.

_enjn 39 days ago |

Interesting that you manually mapped GET→resources and POST→tools. We hit the same pattern with ToolMesh.io so often that we built a declarative format for it — DADL, a YAML file that describes the REST API mapping, and the gateway generates the MCP server at runtime. No code, no deployment per API. The boilerplate of wrapping every REST API into an MCP server is probably the biggest adoption blocker right now.