docs(proposal): add MCP server proposal

[devGPP23]

What this PR does

This PR adds my project proposal for the LFX Mentorship 2026.

The idea is to build an MCP (Model Context Protocol) server for Kmesh. Right now, debugging Kmesh usually means running a bunch of kmeshctl commands and manually reading heavy xDS/eBPF dumps.

This proposal introduces an MCP server that acts as a bridge, allowing AI agents (like Claude or Cursor) to directly fetch and analyze Kmesh data. So instead of manual debugging, users can just ask their AI questions like "Why is service A failing?", and the AI will chain our MCP tools to find the root cause automatically.

I've included the architecture, the approach for safely port-forwarding the status server, and a 12-week timeline. Would love to get your thoughts and feedback on this.

Fixes #1800

#Special notes for your reviewer:

• I've included a couple of Mermaid diagrams to show the tool execution flow and lifecycle. Let me know if the architecture makes sense or if we need to change the approach anywhere.

[kmesh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign lizhencheng9527 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Copilot]

🟡 Changes recommended

The MCP listener architecture lacks required client authentication, authorization, RBAC, and listener-binding/TLS controls.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR adds an LFX Mentorship proposal for an AI-native Kmesh MCP server.

Changes:

• Defines goals, scope, and security approach.
• Adds Mermaid architecture and lifecycle diagrams.
• Provides a 12-week implementation timeline.

File summaries

File	Summary	Findings
docs/proposal/MCP_Server_AI_Native_Kmesh.md	Adds the MCP server proposal, architecture, security approach, and timeline.	Nit: capitalize the sentence after the period. Critical: add MCP client authentication/authorization, least-privilege RBAC, and listener-binding/TLS policy.

Review details

Suppressed comments (2)

docs/proposal/MCP_Server_AI_Native_Kmesh.md:70

• The diagram introduces get_kmesh_daemons and get_xds_config, but the planned core API in the linked issue uses list_daemon_pods and config_dump. Keeping these names inconsistent makes the proposal and implementation/client examples disagree; use the canonical tool names here or explicitly define aliases.

        C["Tool: get_kmesh_daemons"]
        D["Tool: get_bpf_maps"]
        E["Tool: get_xds_config"]

docs/proposal/MCP_Server_AI_Native_Kmesh.md:158

• The linked issue's tech stack specifies github.com/modelcontextprotocol/go-sdk, but this proposal names the ambiguous mcp-go package and says it generates rules. That can lead the implementation to choose a different SDK and an inaccurate schema model; use the intended module path and describe tool-schema definition accurately.

- **Smart Data Models**: Using the `mcp-go` library to automatically generate the rules so the AI knows exactly what to ask for.

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Five unresolved review comments must be addressed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

docs/proposal/MCP_Server_AI_Native_Kmesh.md:68

• The architecture exposes an MCP endpoint at :8080 but does not define any authentication or authorization for clients. Port-forwarding protects the daemon's backend connection, not the MCP endpoint itself, so a reachable server could expose cluster data; specify the service-account/mTLS/auth-handler boundary and enforce it before describing this path as secure and read-only.

        B["MCP Server (:8080)"]

docs/proposal/MCP_Server_AI_Native_Kmesh.md:25

• The second sentence starts with a lowercase it, which is a grammatical error in the proposal text.

- **The Solution:** This proposal introduces an **MCP (Model Context Protocol) Server** for Kmesh. it works like a translator that lets AI assistants talk directly to Kmesh.

docs/proposal/MCP_Server_AI_Native_Kmesh.md:93

• The text says this is a four-step lifecycle, but the diagram defines Steps 1–8 across two phases. This contradiction makes the proposed process ambiguous; describe it as a two-phase, eight-step lifecycle.

To make sure these tools are built cleanly and securely, every tool will go through a strict, four-step lifecycle:

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Unresolved integration, API, SDK, security-boundary, and port-forwarding design issues remain.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (5)

docs/proposal/MCP_Server_AI_Native_Kmesh.md:189

• The planned get_daemon_health tool is mapped to /debug/ready, but the current handler unconditionally returns 200 OK and even notes that component checks are still TODO. This tool would therefore report a daemon as healthy when only the HTTP server is reachable; either define it as a liveness check or provide a real readiness/health signal before including it as a health tool.

  - Build cluster discovery tools: `get_version`, `list_daemon_pods`, and `get_daemon_health`.

docs/proposal/MCP_Server_AI_Native_Kmesh.md:190

• get_authz_status cannot currently be implemented as the proposed read-only GET against /authz: pkg/status/status_server.go rejects every method except POST, and that POST changes the authz offload setting. Add a read-only status endpoint or remove/replace this tool; otherwise one of the ten core tools will always fail and the read-only guarantee is inaccurate.

  - Build Status Server tools: `config_dump`, `get_bpf_maps`, `get_logger_levels`, and `get_authz_status`.

docs/proposal/MCP_Server_AI_Native_Kmesh.md:79

• The diagram names tools get_kmesh_daemons and get_xds_config, while the workflow and implementation timeline use list_daemon_pods and config_dump. Keeping both spellings makes the proposed tool API ambiguous; use one canonical name for each tool throughout the proposal.

        C["Tool: get_kmesh_daemons"]
        D["Tool: get_bpf_maps"]
        E["Tool: get_xds_config"]

docs/proposal/MCP_Server_AI_Native_Kmesh.md:87

• The architecture shows AI clients connecting directly to :8080 with no authentication or authorization boundary, even though the server can expose cluster-wide config/eBPF data and create Kubernetes port-forwards. Read-only access does not prevent unauthorized reads; define and show the Kubernetes service-account/RBAC or mTLS auth boundary before describing this wiring as secure.

    A -- "JSON-RPC over SSE" --> B

docs/proposal/MCP_Server_AI_Native_Kmesh.md:108

• This workflow creates and closes a Kubernetes port-forward for every tool call. Chained or concurrent AI requests will repeatedly pay API/websocket setup latency and can create a connection burst; define bounded per-pod/session reuse or a concurrency limit, along with timeout and cleanup behavior, for the long-lived MCP server.

*Workflow:* The server dynamically locates the daemon pod using `client-go` -> Sets up a secure port-forward tunnel to `15200` -> Executes the HTTP GET request -> Closes the tunnel.

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

[kmesh-bot]

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[LiZhenCheng9527]

Could we add a compact contract table for the 10 core tools, covering their inputs, backing endpoint or Kubernetes resource, and expected output?

In particular, please clarify how config_dump and get_bpf_maps select between kernel-native and dual-engine modes, and what happens when the requested mode is unavailable on the target daemon. Please also define whether omitting pod_name queries all daemons or selects a single one.

A short table would be sufficient for this proposal;

[LiZhenCheng9527]

Could we make the filtering behavior more explicit rather than describing it as “aggressively” removing boilerplate? An omitted entry could otherwise be mistaken for a missing route or endpoint during diagnosis.