Show HN: An MCP server for Devops automation
2 comments
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.
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.
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.
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.