Have a way to limit subcommands of a tool

[jvitor03]

This is a follow up from #183 (comment)

Context

The PR #193 enables the parameter "context" to be used for a stateless multi-cluster usage, which is useful in a scenario where multiple users access the same MCP server, however with the tool kubectl_context enabled, an LLM can use the subcommand "set", instead of using the parameter "context" directly in the tools, which would make it use the stateful approach again (and possibly affecting other users where the LLM chose to set an context too).

Disabling the kubectl_context using ALLOWED_TOOLS env var is also not optimal, because the tool is still useful for the LLM to list all available clusters in the KUBECONFIG, mainly when the name of the cluster is not used correctly in the prompt.

Issue

Have a way to be able to disable just the subcommand "set" of the kubectl_context tool, while retaining the "get" and "list" subcommands.

As discussed in the other issue, would be useful to have this feature in a generic way, instead of a env var dedicated for just a tool.
e.g. ALLOWED_TOOLS="kubectl_context:get, kubectl_context:list" or an ALLOWED_SUBCOMMANDS env var.

Example

Below there's a practical example based on a fork of an agent using the MCP with kubectl_context disabled vs enabled only for get and list:

---

Objective: list pods of the namespace XXXX in the cluster cluster-2.example.com (cluster name was changed, but is actually bigger than this one)

Prompt: Check all pods of the namespace 'XXXX' in the cluster 'cluster-2'

Agent using the MCP without the context tool (ALLOWED_TOOLS):

I need to check all pods in the 'XXXX' namespace using the 'cluster-2' cluster context. I'll use the kubectl_get tool to list all pods in that specific namespace and context.

... (tries to use kubectl_get with context and gets an error, then proceeds to wrongly use kubectl_get without context to get all contexts)

Action: kubectl_get
Action Input: {"resourceType": "pods", "namespace": "troubleshooter", "context": "cluster-2"}

Final Answer: I attempted to check all pods in the `XXXX` namespace using the `cluster-2` cluster context, but encountered the following issues:

**❌ Context Error**: The context `cluster-2` does not exist in the current kubeconfig. The error message was:
error: context "cluster-2" does not exist

Agent using the MCP with the modified kubectl_context tool (list, get only):

I need to check all pods in the 'XXXX' namespace in the 'cluster-2' cluster. I'll use the kubectl_get tool to list all pods in that specific namespace and context.

... (tries to use kubectl_get and gets the same error as above)

thought: The context "cluster-2" doesn't exist. Let me first check what contexts are available in the cluster to see the correct context name.

Action: kubectl_context
Action Input: {"operation": "list", "showCurrent": true}

I can see the available contexts. The correct context name for the cluster-2 cluster is `cluster-2.example.com`. Now let me check all pods in the 'XXXX' namespace using this correct context.

... (sucessfully uses the kubectl_get tool)

Action: kubectl_get
Action Input: {"resourceType": "pods", "namespace": "XXXX", "context": "cluster-2.example.com"}

I now know the final answer

Final Answer: I successfully checked all pods in the `XXXX` namespace in the cluster-2 cluster. Here are the results:

[jvitor03]

@Flux159 although we discussed about having a generic approach, seems like only two tools have subcommands, that is the kubectl_context and kubectl_rollout, all others don't have subcommands, only upper level command that is already split by tool (eg. kubectl_get, kubectl_delete, install__helm_chart, upgrade_helm_chart etc).

So I think creating a generic env to filter per tool will only add more complexity for something that would only be used by at most two tools (and only one of them has a need to be filtered now)

So I see two aporaches that can simplify the issue:

• A single KUBECTL_SUBCOMMANDS_READONLY, that would affect only those tools with subcommands
• Or since we are talking about only two tools, one env for each, KUBECTL_CONTEXT_READONLY and a KUBECTL_ROLLOUT_READONLY in the future.

eg.
In the case of kubectl_context, it would just removes the set, leaving the list and get and in the case of the kubectl_rollout it would remove the restart, undo, pause and resume, leaving the status and history.

Looking at those tools code, the implementation should be simple:

const operationEnum = envConfig.kubectlSubcommandsReadOnly ? ["list", "get"] : ["list", "get", "set"];
const operationDescription = envConfig.kubectlSubcommandsReadOnly 
  ? "Operation to perform: list contexts or get current context" : "Operation to perform: list contexts, get current context, or set current context";
const schemaDescription = envConfig.kubectlSubcommandsReadOnly
  ? "Manage Kubernetes contexts - list or get the current context" : "Manage Kubernetes contexts - list, get, or set the current context";

and similar for the kubectl_rollout

WDYT?

[rr-paras-patel]

Hi, @jvitor03
have you tried with different LLM models e.g. Sonnet 3.7, 4.0 etc ?

[jvitor03]

I have tested the context limitation with Sonnet 4.0 and Opus, it worked as expected (and Im currently using this way in our Alpha), but we were dicussing about how would be the best way to configure this in the MCP

[rr-paras-patel]

On long term basis for multi cluster suport via Remote MCP hosting. we need to rely on --context we can't keep changing kube_context.