KEP: Kubeflow MCP Server - AI-Powered Training Interface

[abhijeet-dhumal]

Description

This KEP proposes adding a Model Context Protocol (MCP) Server to the Kubeflow SDK.

Problem: Using Kubeflow Training requires Python SDK expertise + Kubernetes knowledge. Users must understand TrainerClient, BuiltinTrainer, CustomTrainer, PVCs, RBAC, and multiple tools.

Solution: MCP server wraps the existing SDK, enabling AI agents (Claude, Cursor, VS Code Copilot) to interact with training through natural language—no code duplication.

Related: kubeflow/sdk#238

[tonystark101-debug]

Hi! 👋

I've opened the first PR for the MCP server foundation: Kubeflow/sdk#265

What's included:

FastMCP server setup in kubeflow/mcp/
Two discovery tools:
get_cluster_info() - Check cluster connectivity and K8s version
get_cluster_resources() - Get GPU/CPU/memory info across nodes
24 tests total (15 for discovery tools, 5 for server setup, 4 integration tests)
Added mcp>=1.0.0 dependency
This is the foundation - just discovery tools for now. Training tools will come in follow-up PRs. We're wrapping the existing SDK (no code duplication), and for this PR we're just using the K8s API directly since we're only doing discovery.

All tests pass locally. Would appreciate any feedback on the structure or approach!
@abhijeet-dhumal

[khushiwayal]

Hi, I am reviewing this KEP after a discussion with @jaiakash on Slack. The phased approach makes a lot of sense, especially starting with the discovery tools.

I have been working on the OptimizerClient documentation (PR #304) and I am very interested in helping with Phase 2, specifically the Training and Optimizer tools. I will be following the progress here to make sure my GSoC proposal stays aligned with this architecture. Looking forward to it!

[abhijeet-dhumal]

👋 Hi everyone!
Apologies for the silence on this, we've had a busy few weeks..
The proposal KEP-936: Kubeflow MCP Server is ready for review again - a proposal to let AI agents (Claude, Cursor, etc.) interact with Kubeflow Trainer through natural language.
Would really appreciate any feedback on the proposal :

• KEP PR : Add KEP-936: Introduce Kubeflow-MCP proposal for AI-Powered Training … #937
• Tracking issue : Built an MCP Server for Kubeflow SDK sdk#238
• Trainer extensibility: KEP-2839: Kubeflow Dynamic LLM Trainer Framework trainer#2839

I've still some bits to work through, but I'd appreciate any early feedback on the approach I've taken. I'm hoping I can raise something soon so folk can start taking a look, even if it's only a draft 🤞

[MansiSingh17]

Hi @abhijeet-dhumal @jaiakash 👋 I've reviewed KEP-936 along with sdk#238 and KEP-2839. Really well thought out proposal — the connection between the MCP tool layer and the Dynamic LLM Trainer Framework makes the extensibility story very compelling.
I'm a GSoC 2026 applicant and have already made two contributions to kubeflow/sdk (PR #311 — structured logging, PR #312 — TrainerClient examples) to get familiar with the codebase.
I'm particularly interested in contributing to Phase 3 (Multi-Tenancy/Security) and Phase 4 (Job Lifecycle). I have production experience building Python backend services, containerized microservices with Docker and Kubernetes, and implementing CI/CD pipelines, which I think maps well to the Istio/impersonation work in Phase 3 and the suspend/resume/checkpoint management in Phase 4.
Happy to coordinate with other contributors to avoid overlap and align my GSoC proposal with the architecture you've laid out here. Looking forward to contributing!

[khushiwayal]

Hi @abhijeet-dhumal, thanks for the update and for sharing the detailed proposal.
Following up on your request for feedback, I have been looking into the technical requirements for the Phase 2 tools (Training & Optimizer).
One thing I noticed during my audit of the SDK is that many core clients still rely on legacy print() statements for reporting job status. For the MCP server to provide reliable, machine-readable feedback to an AI agent, I believe a critical foundation will be refactoring these into structured Python logging (as discussed in Issue #85). This would allow the MCP server to stream event-based updates to the AI Host in real-time.

I am very excited about this architecture and would love to help refine the tool schemas to ensure a seamless bridge between the SDK and AI agents. Looking forward to the roadmap.

[Sridhar1030]

Hello @abhijeet-dhumal @jaiakash @dhanishaphadate

I’m Sridhar, a GSoC 2026 applicant interested in the MCP Server for Kubeflow SDK project. I’ve gone through KEP-936 along with the related discussions, and I really like how the MCP layer is being structured to enable LLM-driven workflows on top of Kubeflow.

I’ve been actively contributing across Kubeflow:
Pipelines PR #13009
Pipelines PR ##12844
Trainer PR #3308
SDK PR #332
Website PR #4278

While they are small contributions , they helped me understand different parts of the ecosystem and how the components interact.

I’m particularly interested in:

Phase 2 (Resource Management) because reliable pre-flight validation and resource estimation are key for making MCP tools practical in real cluster environments

Phase 5 (Optimizer & Hub) since integrating components like Model Registry and extending MCP beyond Trainer enables more powerful workflows

Phase 6 (Future Clients) as expanding MCP support to components like Pipelines and Spark makes the system more extensible and aligned with the broader Kubeflow ecosystem

My background is in Python backend systems and Kubernetes, and I currently work with Kubeflow-based(especially kubeflow trainer) workflows as part of the Red Hat OpenShift AI team, so these areas align well with my experience.

I’m preparing my proposal with a focus on extending the existing MCP server, especially around lifecycle management, observability, and extensibility.
Looking forward to contributing and aligning with the direction of the project.

[Ritikroshan4857]

Hello @abhijeet-dhumal @jaiakash
I'm Ritik, a Data Science undergraduate applying for GSoC 2026. I've read KEP-936, the related SDK issue #238, and the MCP proposal #937.
What excites me most about this project is the main problem it addresses. Right now, using Kubeflow Training requires both deep SDK expertise and Kubernetes knowledge. The MCP server approach wraps the existing SDK to allow natural language interactions with AI agents like Claude and Cursor. This solution removes the barrier completely.
I'm particularly interested in contributing to Phase 1 (Discovery Tools) as a starting point. I'm focused on the get_cluster_info() and get_cluster_resources() tools since I see from tonystark101-debug's PR #265 that the foundation is already laid. I’d like to build on this further.
My background includes Python, basic machine learning, and I’m currently learning Kubernetes and MLOps. I'm a quick learner and will be available full time this summer.
I have two specific questions:

1. For GSoC 2026, which phases are still open for contributors?
2. Is there a small starter task or documentation issue I can pick up immediately to get familiar with the codebase before March 31?

Thank you for your work. The vision of LLM-driven Kubeflow workflows is exactly where the industry is heading. I'm looking forward to contributing