Standardize MCP Servers and Tool Ecosystem Across Cloud-Native Categories

[zanetworker]

Motivation

MCP (Model Context Protocol) enables natural language-driven interfaces by bridging user intent with model-aligned execution. It makes it possible to perform cloud-native tasks via NL inputs, and unlocks new patterns of automation and delegation.

Today, there are a myriad of MCP servers covering a broad range of functionality across the cloud-native ecosystem, and it's not stopping. Currently, multiple servers often perform overlapping roles within each cloud-native category category. For example, see the below for just a sample of existing kubernetes-mcp-servers:

• https://github.com/alexei-led/k8s-mcp-server
• https://github.com/Flux159/mcp-server-kubernetes
• https://github.com/manusa/kubernetes-mcp-server
• https://github.com/strowk/mcp-k8s-go
• https://github.com/weibaohui/k8m
• https://github.com/weibaohui/kom
• https://github.com/wenhuwang/mcp-k8s-eye
• https://github.com/silenceper/mcp-k8s
• https://github.com/manusa/kubernetes-mcp-server
• https://github.com/StacklokLabs/mkp

This fragmentation leads to confusion, inconsistent behavior, and inefficient tool performance especially when used in the same environment. To avoid chaos, each category needs a single (or a handful) well-tested/verified MCP server(s) that speaks for its domain/category.

Benefits

• Clarity: One MCP server per category ensures a clear entry point.
• Precision: Contextually accurate and scoped responses from each server.
• Interoperability: Composable through uniform interfaces and shared context schema.
• Maintainability: Reduces duplication and increases focus.
• Security: Easier to audit and validate.

Vision

Establish a unified Model Context Protocol ecosystem: Each CNCF category is represented by a single (or a handful) well-tested/verified MCP server(s) that provides verified, standardized, natural language interfaces to control, inspect, and automate its domain/category. These servers should share a common interface spec, interoperate through NL-linked graph state, and follow a modular design. I.e., for each cloud-native category:

• Define a single authoritative MCP server implementation.
• Ensure it supports a defined set of NL intents and outputs predictable, explainable responses.
• Integrate with existing tools (e.g. kubectl, Terraform, Helm).
• Be composable with other MCP servers (category-to-category delegation).
• Follow the MCP protocol: context-aware model routing, intent resolution, scoped control surface.

References that can serve as initial MCP server examples:

Kubernetes Cluster:

• https://github.com/manusa/kubernetes-mcp-server
• https://github.com/alexei-led/k8s-mcp-server
• https://github.com/Flux159/mcp-server-kubernetes
• https://github.com/manusa/kubernetes-mcp-server
• https://github.com/strowk/mcp-k8s-go
• https://github.com/weibaohui/k8m
• https://github.com/silenceper/mcp-k8s
• https://github.com/wenhuwang/mcp-k8s-eye

Multi-cluster:
https://github.com/weibaohui/k8m

CLI / Kubectl Interface:
https://github.com/rohitg00/kubectl-mcp-server

Observability / Diagnostics:
https://github.com/wenhuwang/mcp-k8s-eye

IaC Related:
https://github.com/nwiizo/tfmcp (Terraform)

Target Categories from CNCF Landscape

• Application Definition & Image Build
• Orchestration & Management
• Runtime
• Provisioning
• Observability & Analysis
• Continuous Integration & Delivery
• Platform
• Developer Experience
• Security & Compliance
• Networking
• Service Proxy
• API Gateway
• Service Mesh
• Remote Procedure Call
• Coordination & Service Discovery
• Scheduling & Orchestration
• Database
• Streaming & Messaging
• Cloud Native Storage
• Container Runtime
• Container Registry
• Key Management
• Automation & Configuration
• Chaos Engineering
• Continuous Optimization
• Feature Flagging

[electrocucaracha]

Besides the fragmentation, one of the major concerns with MCP servers are security. I'm not sure if all those implementations have security in mind, which eventually can create backdoors to the cluster. Auth0 provides a great post about the authorization efforts.

[joshhalley]

In addition to standardising around security, observability and explainability are also critical components in this domain. A mandatory OTEL instrumentation with the use of common semantic conventions and hooks would go a long way to ensure that whatever is developed allows for flexibility, interoperability and scale considerations.

[zanetworker]

Related work: https://docs.google.com/document/d/1BlmHq5uPyBUDlppYqAAzslVbAO8hilgjqZUTaNXUhKM/edit?tab=t.0#heading=h.h212y3qkc7m6

[zanetworker]

From Andrew Block: https://docs.google.com/document/d/1Xsu7tWUuWZdgfcSehy7Tu9rvsK6NdBHadQOZ-4gJn5M/edit?tab=t.0#heading=h.fuypivupqkjy

[JAORMX]

Hey folks, I'm one of the maintainers for https://github.com/StacklokLabs/mkp . Happy to represent it if folks are interested in it. Andrew Block and I kicked off the document that @zanetworker posted above comparing the different k8s MCP implementations.

[manusa]

I'm the maintainer of https://github.com/manusa/kubernetes-mcp-server
Happy to present too 😉

[mrunalp]

We agree that it makes sense to have a MCP server for each category. Each project would have strong opinions on how AI agents are interacting with them. From that perspective, each project would create or support an implementation representing their category. We are driving this conversation within the k8s community to that effect https://docs.google.com/document/d/13OJvWKGKZL0V4nPpv9anitL5je92FCdQyXePcrY2N84/edit?tab=t.0. Your thoughts are welcome on the WG proposal, rationale, and working model would help provide clarity on paths forward, and possibly a template for other projects to make progress adjacent to Kubernetes. Finally, we think there is a potential room for evaluating how Kubernetes resource model (e.g. api conventions, or crd annotations) could provide hints for how to respond to AI systems (for example, note a field is private to an ai system, etc.) and this could benefit the ecosystem projects that build around Kubernetes. If others had ideas in this space, we wanted to explore that in the WG.

[BenTheElder]

We agree that it makes sense to have a MCP server for each category. Each project would have strong opinions on how AI agents are interacting with them. From that perspective, each project would create or support an implementation representing their category. We are driving this conversation within the k8s community to that effect https://docs.google.com/document/d/13OJvWKGKZL0V4nPpv9anitL5je92FCdQyXePcrY2N84/edit?tab=t.0.

Note that there is not yet agreement in Kubernetes that we should be hosting an MCP ourselves versus CNCF projects, and a workgroup would be a place to discuss related topics and make recommendations (e.g. the security posture, any changes we need to the API metadata, etc).

I don't think projects necessarily need to own the MCP implementation versus providing guidance about security posture, sensitive data redaction, and other interaction details, this space is evolving rapidly and we should avoid king-making both with respect to MCP servers (and similar efforts like A2A) and with respect to models.

[zanetworker]

Thank Mrunal, Ben for your comments.

This issue is a projection of the community's interest in having canonical sources of truth for MCP server implementation (given the scattering around implementations today), not only for Kubernetes but for other projects in the CNCF ecosystem. Ideally, MCP servers are maintained by the same communities of their home projects, analogous to how companies release MCP servers. For example, Atlassian’s Jira and Confluence, Zapier, Cloudflare, Intercom, Asana, Square, Sentry, PayPal, Linear, and Plaid, Github, etc. This IMO helps with maintenance on the long run.

That said, if there are other ways to get the same communities to contribute and maintain canonical implementations for MCP servers, we from the CN AI WG (now the CNCF AI subproject) would be happy to help/contribute.

[terrytangyuan]

Just to add to @zanetworker's point here: an Argo CD MCP Server has been created and maintained by the Argo maintainers.

[rr-paras-patel]

One of the maintainer for most downloaded and stared k8s mcp server here. Let me know how can I help and standardize kubernetes mcp server with CNCF community. Thanks @raravena80 for bringing this forward.

[zanetworker]

@caniszczyk FYI, also related to the repo topic (a place to host the ref implementations for MCP servers in different categories).

[dims]

for those who are asking for "canonical" - please review this TOC principle - https://github.com/cncf/toc/blob/main/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all

for those who are asking for repo - the most appropriate way is to file for a sandbox project.

[zanetworker]

@dims how is this (Mcp-kubernetes for example) different than some of the projects here: https://github.com/kubernetes-sigs, these are reference implementations maintained by the kubernetes community or?