Add scale_resource tool

[Cali0707]

After running a first set of evals (using the tasks from kubectl-ai's evals) agains this MCP server, using frontier models and agents in gpt-5 and claude code, the frontier models failed consistently on tasks related to scaling resources.

We should add a scale_resource tool that can operate on anything that implements the scale subresource

[Cali0707]

Thinking a bit more, we probably want a get_scale tool as well

[manusa]

scale_resource accepting an enum of resource types to scale sound really good and optimized the number of tools.
Not sure about get_scale, what would that be needed for? Can't resources_get provide that information already?

[Cali0707]

Not sure about get_scale, what would that be needed for? Can't resources_get provide that information already?

I'm also not 100% sure on this tool, will make a decision based on evals. My thinking is it may help models to be able to interact with the scale subresource, especially because the subresource allows for the specReplicasPath and statusReplicasPath to be defined within a CRD, and it may not be at the place the LLM expects: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource

[manusa]

Maybe we can use the same tool as a query tool.

resources_scale($apiVersion, $kind, $replicas)

$apiVersion and $kind are required.

$replicas is optional, if specified it will set the field.
If not provided, it returns the current values.

The tool should always return the spec and status values.

[Cali0707]

Maybe we can use the same tool as a query tool.

Yes that is a good idea to start

At some point I would like to eval to see if models are able to figure this schema out (especially smaller ones)

[manusa]

Maybe we can use the same tool as a query tool.

Yes that is a good idea to start

At some point I would like to eval to see if models are able to figure this schema out (especially smaller ones)

Smaller models (<8b) will have a hard time figuring this out. Adding the hints for the apiVersion, kind helps a little:

kubernetes-mcp-server/pkg/toolsets/core/resources.go

Lines 18 to 22 in 792d2f5

	commonApiVersion := "v1 Pod, v1 Service, v1 Node, apps/v1 Deployment, networking.k8s.io/v1 Ingress"
	if o.IsOpenShift(context.Background()) {
	commonApiVersion += ", route.openshift.io/v1 Route"
	}
	commonApiVersion = fmt.Sprintf("(common apiVersion and kind include: %s)", commonApiVersion)

kubernetes-mcp-server/pkg/toolsets/core/resources.go

Line 32 in 792d2f5

Description: "apiVersion of the resources (examples of valid apiVersion are: v1, apps/v1, networking.k8s.io/v1)",

AFAIR with these I was able to make some of the smaller models work.

For the scale, my gut feeling tells me that unless we have specific deployments_scale, statefulset_scale, xxx_scale, etc. it'll be hard to find the right combination of tool descriptions that enable the tool for most of the smaller models.

Being able to set or provide context to the system prompt as in modelcontextprotocol/modelcontextprotocol#1137 would also be beneficial for this scenario (Small models with generic tools).