[FEATURE] Add a limit parameter to k8s_get_resources to bound context growth

kubectl get のラッパーである k8s_get_resources から開始し、all_namespaces と各出力形式がどのように処理されるかを追跡します。デフォルトが無制限のままになるのか有限になるのかを解決し、そのうえで、JSON の有効性を維持し、YAML を指定どおりに処理しながら、limit と切り捨ての合計値が正しく表現されることを確認します。

Problem

k8s_get_resources wraps kubectl get and has no way to bound how much it returns. On a large cluster an agent that calls it with all_namespaces=true gets every row of every namespace in a single tool result, which goes straight into the model's context.

In our production estate this is the single largest source of context growth. An agent turn that issued a handful of cluster-wide k8s_get_resources calls reached several million input tokens and exhausted the model's context window, which ends the turn with an error rather than a large-but-usable answer. The failure is also expensive, because the oversized listing is paid for on every subsequent turn that carries the history.

Prompt guidance alone has not been enough for us. Telling the agent to query narrowly reduces how often it happens, but the tool still permits an unbounded listing, so a single unlucky call undoes it. The parameters today are resource_type, resource_name, namespace, all_namespaces and output — none of them cap result size.

Proposal

Add an optional limit parameter to k8s_get_resources that caps the number of resources returned, with limit=0 returning everything.

Two details matter for it to be safe:

• The truncated result should say it was truncated and give the totals. A silently shortened listing reads as complete, so the model draws conclusions from partial data — which is worse than the original problem.
• Truncation has to respect the output format. Slicing lines out of a -o json document would return an invalid one, so JSON should be cut at its items array and YAML left alone.

Whether the default should be a finite cap or unlimited is the main open question. A finite default is what actually protects agents that do not know to pass the parameter, but it changes behaviour for existing callers. Happy to follow whichever the maintainers prefer.

I have a change ready and will open a PR against this issue.