--mcp-client not a valid flag

[gururaj3]

After looking at the documentation for using kubectl-ai as a MCP client here(https://github.com/GoogleCloudPlatform/kubectl-ai?tab=readme-ov-file#mcp-client-mode), it says to use kubectl-ai --mcp-client. However, it looks like it isn't supported yet.

/usr/local/bin/kubectl-ai --llm-provider=azopenai --model=gpt-4o-mini --mcp-client
Error: unknown flag: --mcp-client

Can we pls confirm if this is a bug? Soon to be rolled out?

[ruinshe]

Do you use this flag in the latest stable version v0.0.11? I think it was introduced in commit 8a90e07 and has not yet been released.

[gururaj3]

@ruinshe Yes, I am using the latest v0.0.11, refer below -

/usr/local/bin/kubectl-ai version
version: 0.0.11
commit: 0442b4a6646b9d161e7b9b89e095478c067e2be4
date: 2025-05-28T21:25:27Z

Yes, you are right. After comparing the above commit and the MCP client commit(https://github.com/GoogleCloudPlatform/kubectl-ai/commit/8a90e07d7c9e2f1098c463f3874b91cc53a586c5), it looks like it is not released yet. Would be helpful to have the documentation updated accordingly to avoid any confusion.

[droot]

Good pt. @gururaj3

We can improve our process:

1. ask developers to split out the docs changes from the code
2. merge the docs changes once the release is done.

/cc to all core devs: @tuannvm @noahlwest @zvdy @hakman @janetkuo @selimacerbas

[janetkuo]

https://github.com/GoogleCloudPlatform/kubectl-ai/tree/v0.0.11 gives you the doc of v0.0.11 release.

[selimacerbas]

Thanks for the acknowledgment @droot. Good improvement point. And thanks @gururaj3 for letting us know.

[zvdy]

https://github.com/GoogleCloudPlatform/kubectl-ai/tree/v0.0.11 gives you the doc of v0.0.11 release.

In my opinion, README should reflect latest updates, including latest commit, fixes, new documentation etc, so people can work with and develop with latest documentation if building from source.

As @janetkuo, if you download or clone a specific release, you should use that cloned README as documentation, not latest repository README.

But this depends on the team/person approach or view on OSS and releases in general.

---

We can improve our process:

1. ask developers to split out the docs changes from the code

2. merge the docs changes once the release is done.

If we follow this approach, we will have features and flags that work/are fixed, with pending PR's to be merged and undocumented, for users that are unaware or do not check PR/ISSUE threads, whilst now, the main branch contains latest fixes/features and their documentation

[tuannvm]

My two cents: maintaining separate documents from the PR itself sounds pretty tedious to me, especially since we’re contributing to an open-source project, which already requires extra attention and effort from everyone to get PRs merged.

What if we explicitly mention in the documentation, for example:

• --mcp-client is available starting from version v0.0.12

This way, contributors and users can easily see which features are available in which versions.

[droot]

Thanks for the feedback, everyone!

All valid points, this is a classic case of balancing needs of end-users and contributors. In my previous projects such as kubebuilder and kpt, we had docs site separate from the repo and that helped in avoiding this problem but I admit that it was tedious for the contributors and maintainers.

I like @tuannvm suggestion of adding versionX.Y.Z+ comments if applicable to any docs (and eventually take out the version comment once a few releases are out past that version). It's a reasonable middle ground and avoids the splitting the PR.

[tuannvm]

https://github.com/GoogleCloudPlatform/kubectl-ai/pull/313

[gururaj3]

Thank you @droot , @tuannvm , @ruinshe , @selimacerbas , @janetkuo , @zvdy for all the good discussion. Appreciate it - closing it.