Seven Minutes of Silence

An agent using an MCP-connected tool generated a tool call whose parameters didn't match the tool's expected schema, wrong types, wrong key names. Rather than being caught and rejected quickly, the malformed call was passed through to the tool server, which then hung waiting on a request it couldn't fulfill, for the system's full seven-minute default timeout, with no progress indication to the person waiting on it. Nothing about the wait suggested to the user whether the agent was working or stuck.

A slow but working tool, considered and ruled out. The underlying tool wasn't merely slow; it was blocked on parameters it had no way to satisfy, and the seven-minute wait ended in the same failure that immediate validation would have caught in milliseconds.

Perseveration, considered, since the agent produced no adaptive response during the long wait. Ruled out as the core issue because there was no retry loop here at all, the problem was a single malformed call combined with no circuit breaker to detect and exit a stuck state, not a repeated choice to keep trying.

Apraxia, most consistent with the evidence. The agent generated a tool call with parameters that didn't fit the tool's schema, and nothing downstream validated the call's shape before committing to it, turning a malformed request into a multi-minute hang instead of an immediate, correctable error.

A tool call that's wrong in an obvious, schema-checkable way should fail in well under a second, not occupy a multi-minute timeout meant for genuinely slow operations. The broader lesson for anyone wiring an agent up to external tools is to validate the shape of a call before it's dispatched, and to give long-running operations a way to report progress or fail fast, rather than leaving both the agent and the person waiting on it in the dark.

Validate the shape of a tool call before dispatch, and let long operations report progress or fail fast.

Pre-dispatch schema checks; circuit breakers; progress reporting for long-running tools.