Vendors now ship their own MCP servers

For most of MCP’s short life, a server for your infrastructure meant someone’s weekend wrapper around a CLI. That’s changing where it matters most. The companies that own the tools are now shipping the servers themselves.

You can see it in the repos. HashiCorp’s terraform-mcp-server is at v1.3.0 under MPL-2.0, with 1,551 stars and commits this week. Docker’s mcp-gateway (MIT, 1,607 stars) has no GitHub releases at all, because it ships inside Docker Desktop’s MCP Toolkit. There the server is part of the product, not a side project. The kubernetes-mcp-server from the containers org (Apache-2.0, 2,169 stars, v0.0.67) covers Kubernetes and OpenShift and got a commit today. GitHub’s own github-mcp-server is at v2.0.2 with 33,776 stars, and Cloudflare maintains its own set of servers.

None of the three infra servers is a star rocket. Each adds roughly 19 to 24 stars a week, and that slow pace is the signal. People install these because they run Terraform, Docker or a cluster, not because the repo trended for a day.

For builders, a first-party server changes three things. It tracks the vendor’s API as the API moves, it uses the vendor’s own auth model, and it gets fixed by people who can see the backend. A community wrapper can only chase all three. The trade-off is control. A vendor server exposes what the vendor chooses to expose, on the vendor’s schedule. It can also live inside a product, as Docker’s does, rather than in a repo you can pin.

The practical rule follows from that. If the vendor ships a server, start there. Check its license (Apache-2.0, MPL-2.0 and MIT here, all open source) and how often it releases. Keep a community server only for the gaps the vendor hasn’t covered yet.

The durable lesson: once a tool’s owner ships the MCP server, the wrapper you built becomes something you maintain alone. Prefer the server run by whoever controls the API.