Thanks for the feedback, @rr-paras-patel. I will make the changes accordingly

@rr-paras-patel I'm not against having a separate cp command instead of overloading generic.

Couple of reasons:

• You can allow / disallow any tools you want now with ALLOWED_TOOLS env var when spawning the mcp server, allows you to reduce context. The other thing is that the mcp spec supports dynamic tool updates now https://modelcontextprotocol.io/docs/concepts/tools#tool-discovery-and-updates - so in theory clients could make some request to modify tools at runtime rather than at process spawn time.
• Like before, I think that it's on clients to let users choose which tools they want to use from a given mcp, not on MCP servers to optimize for client context. Also since llm input context will continue to get longer (128k relatively standard now & 1-2M for Gemini) & models will continue to get better at handling more tools, I don't want to prematurely optimize for context size.
• Having a separate tool allows users to restrict it, ex: I want to enable copying files into or out of a container, but not letting users do generic commands like delete a pod - I wouldn't be able to do this currently.
• For kubectl cp in particular, I see it as a different operation than doing "generic" operations on pods, services, resources, etc. because it's doing actions inside of specific containers (similarly exec_in_pod is also doing actions inside of a container & that is split out).

The other thing is that if we're worried about context from tool calls, we should add that to our CI / CD and measure it for every change - then can make pretty simple data driven decisions (context over X tokens means we need to reduce / refactor, etc.). In this case I don't actually know how many tokens all our tool calls are using or the additional tokens a single tool call / PR is adding (I'm guessing ~90-100?).

If this was being developed for a company, I would say just add anonymized telemetry so that we could add this feature, see it's usage, and then decide in a future version (~4-5 weeks) if we wanted to remove it because most LLMs are actually using the kubectl_generic tool and kubectl_cp tool doesn't get enough usage / isn't worth splitting out & maintaining. However, since this is an open source project & many people including myself would be opposed to this type of telemetry from the mcp-server, I will most likely reject any telemetry PRs.

Either way - super long wall of text, but I don't think we need to reject only because there's a new tool call / because of context size.

@rr-paras-patel I'm not against having a separate cp command instead of overloading generic.

Couple of reasons:

• You can allow / disallow any tools you want now with ALLOWED_TOOLS env var when spawning the mcp server, allows you to reduce context. The other thing is that the mcp spec supports dynamic tool updates now https://modelcontextprotocol.io/docs/concepts/tools#tool-discovery-and-updates - so in theory clients could make some request to modify tools at runtime rather than at process spawn time.
• Like before, I think that it's on clients to let users choose which tools they want to use from a given mcp, not on MCP servers to optimize for client context. Also since llm input context will continue to get longer (128k relatively standard now & 1-2M for Gemini) & models will continue to get better at handling more tools, I don't want to prematurely optimize for context size.
• Having a separate tool allows users to restrict it, ex: I want to enable copying files into or out of a container, but not letting users do generic commands like delete a pod - I wouldn't be able to do this currently.
• For kubectl cp in particular, I see it as a different operation than doing "generic" operations on pods, services, resources, etc. because it's doing actions inside of specific containers (similarly exec_in_pod is also doing actions inside of a container & that is split out).

The other thing is that if we're worried about context from tool calls, we should add that to our CI / CD and measure it for every change - then can make pretty simple data driven decisions (context over X tokens means we need to reduce / refactor, etc.). In this case I don't actually know how many tokens all our tool calls are using or the additional tokens a single tool call / PR is adding (I'm guessing ~90-100?).

If this was being developed for a company, I would say just add anonymized telemetry so that we could add this feature, see it's usage, and then decide in a future version (~4-5 weeks) if we wanted to remove it because most LLMs are actually using the kubectl_generic tool and kubectl_cp tool doesn't get enough usage / isn't worth splitting out & maintaining. However, since this is an open source project & many people including myself would be opposed to this type of telemetry from the mcp-server, I will most likely reject any telemetry PRs.

Either way - super long wall of text, but I don't think we need to reject only because there's a new tool call / because of context size.

ok, let's move forward with new tool then.
Tools like cursor gives warning pretty much after having total 40 tools loaded and also it doesn't provide way to enable selective tools.

while VS Code do have capability to enable selected tools.

@Flux159 ,I am facing an issue with the GitHub workflow tests, whereas they are working fine on my local machine. I am debugging the issue.

@Gokul-Mylsami You're able to see the errors right?

 ❯ tests/kubectl-cp.test.ts (2 tests | 2 failed) 101911ms
   × test kubectl cp command > should copy file from pod to local machine 50938ms
     → MCP error -32603: MCP error -32603: Tool execution failed: Error: Failed to copy file: Command failed: kubectl cp test-cp-vt3m29fz/cp-test-pod-6kbgr1ti:/tmp/testfile.txt /tmp/cp-test-el7wdi9d/copied-testfile.txt -c test-container
error: unable to upgrade connection: Forbidden

   × test kubectl cp command > should copy file from local machine to pod 50972ms
     → MCP error -32603: MCP error -32603: Tool execution failed: Error: Failed to copy file: Command failed: kubectl cp /tmp/cp-test-el7wdi9d/test-upload.txt test-cp-m5hsi3ha/cp-test-pod-6kbgr1ti:/tmp/uploaded-file.txt -c test-container
error: unable to upgrade connection: Forbidden

Unclear if this is related to this. I don't think that minikube should be an issue here?