fix(k8s): describe the scope and image columns k8s_get_resources actually has - #70
Open
garlicKim21 wants to merge 1 commit into
Open
fix(k8s): describe the scope and image columns k8s_get_resources actually has#70garlicKim21 wants to merge 1 commit into
garlicKim21 wants to merge 1 commit into
Conversation
…ally has
The description is one line — "Get Kubernetes resources using kubectl" — and
leaves out two behaviours an agent cannot infer. Both produced wrong answers
for me this week with a third-party agent.
Default scope is the tool's own namespace, not the cluster. Asked to check the
cluster, the agent called k8s_get_resources{resource_type: "pod"} and got back
only the namespace kagent runs in, reported that as the cluster, and concluded
nothing needed attention. "Query all namespaces (true/false)" says what the
flag does, never what omitting it means.
`-o wide` shows images for workloads but not for pods. After the agent's
discovery instructions were widened it surveyed pods across all namespaces — a
listing whose columns are NAME/READY/STATUS/RESTARTS/AGE/IP/NODE and no image.
With no version in anything it had read, the model supplied a plausible one for
a CNI running a quite different version, and every comparison after that was
confidently wrong with no signal until a human noticed.
helm/agents/k8s/templates/agent.yaml in the main repo already tells its own
agent "always prefer wide output unless specified otherwise". That knowledge
lives in one agent's prompt; every other agent rediscovers it by failing.
all_namespaces is declared as a string and was compared with == "true", so a
model emitting a JSON boolean had --all-namespaces dropped silently and got a
single-namespace answer with no error. The repo's own e2e mock in the main repo
passes it as a boolean. mcp.ParseBoolean uses cast.ToBool and accepts both, so
the string spelling keeps working.
Signed-off-by: Golden Garlic <148346166+garlicKim21@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
k8s_get_resourcesis described as "Get Kubernetes resources using kubectl".Two behaviours an agent cannot infer are missing from that line, and both
produced wrong answers for me this week with a third-party agent.
1. Default scope is the tool's own namespace, not the cluster.
Asked to check the cluster, the agent called
k8s_get_resources{resource_type: "pod"}and received only the namespace kagentruns in. It reported that as the cluster and concluded nothing needed attention.
"Query all namespaces (true/false)"says what the flag does — never whatomitting it means.
2.
-o wideshows images for workloads but not for pods.After the agent's discovery instructions were widened, it surveyed pods across
all namespaces — a listing whose columns are
NAME/READY/STATUS/RESTARTS/AGE/IP/NODEand no image. With no version anywherein what it had read, the model supplied a plausible one for a DaemonSet-deployed
CNI that was actually running a quite different version, and every comparison
after that was confidently wrong, with no signal until a human noticed.
Notably,
helm/agents/k8s/templates/agent.yamlin the main repo already tellsits own agent "Always prefer wide output unless specified otherwise". That
knowledge lives in one agent's prompt; every other agent has to rediscover it by
failing.
all_namespacestypingall_namespacesis declared as a string and was compared with== "true", so amodel emitting a JSON boolean had
--all-namespacesdropped silently and got asingle-namespace answer with no error — the same symptom as (1), but with the
agent asking correctly. The main repo's own e2e mock
(
go/core/test/e2e/mocks/invoke_inline_agent.json) passes it as a boolean.mcp.ParseBooleanusescast.ToBool, which accepts both spellings, so thestring form keeps working and the schema stays as it is. Happy to change the
declared type instead if you would rather fix it at the schema — that felt like
a compatibility call for maintainers.
Testing
TestHandleKubectlGetEnhancedgains three cases:all_namespacesas a stringand as a boolean both reach kubectl as
--all-namespaces, andfalsekeeps thequery namespaced.
go build ./...,go test ./pkg/k8s/andgo vet ./pkg/k8s/pass.
Verified against
kagent tools 0.2.1as shipped — the deployed MCP serverreports the one-line description and
all_namespacestyped asstring.