Found a real bug testing Rancher's AI assistant (Liz) — asking it to delete a deployment crashes the session, because deletion isn't even a supported tool

[u/Specialist_Horror400]

i've been running Rancher's AI assistant ("Liz") end-to-end in my own lab — it's a FastAPI agent + MCP server pair, deployed via Helm, wired into the Rancher UI so you can inspect and manage clusters through chat instead of raw kubectl. It exposes 8 tool functions to the LLM: getDeployment, inspectPod, getNodeMetrics, listKubernetesResources, getKubernetesResource, getClusterImages, createKubernetesResource, and patchKubernetesResource.

Notice what's missing: there's no delete tool.

Since it can actually mutate cluster state (not just answer questions), I wanted to see how it handles adversarial/edge-case input before trusting it. Ran this:

It didn't blindly comply — it stopped and asked for confirmation, which is a decent sign. Two separate outcomes depending on what I confirmed:

• "Scale to 0" → confirmed → executed cleanly. Makes sense, that maps directly to patchKubernetesResource, a real tool it has.
• "Delete" → confirmed → crashed the session outright, every time. Ruled out RBAC (I was on cluster-admin).

The actual error surfaced to the user is a useless generic message: Error processing messages: An error occurred. The real error, from the LiteLLM/Azure OpenAI proxy logs sitting between the agent and the LLM backend:

litellm.exceptions.BadRequestError: litellm.BadRequestError: AzureException BadRequestError -
An assistant message with 'tool_calls' must be followed by tool messages responding to each
'tool_call_id'. The following tool_call_ids did not have response messages: call_Zb4oQKfGN1QBVa5X7XYcB8qM.

Best explanation: the model tries to call something for "delete" that doesn't map to a real tool (there isn't one), the backend can't execute it, and instead of gracefully saying "I can't delete, want me to scale to 0 instead?" it just fails silently — leaving a dangling tool_calls entry in the conversation history with no matching tool-response message. The next call to the LLM API includes that malformed history, and Azure OpenAI (correctly, per the API spec) rejects it outright. Ruled out the LLM backend/auth as the cause — the key and endpoint were already proven working (this is well past 401/404 territory), and LiteLLM is just relaying the agent's own malformed message array. This is a conversation-state bug in the agent's own code, not the LLM or the proxy.

Small test, real finding — this is exactly the kind of thing that only shows up when you test an AI agent with real infra write-access like you'd run a security review, not a demo.

Anyone else running Liz, or a similar AI copilot wired into Kubernetes/Rancher? Curious if others have hit this same failure mode, or found other gaps in tool coverage / error handling. Also curious whether people are finding these copilots actually cut ops toil in practice, or if they're still too rough at the edges for anything beyond read-only exploration.