What worked · compiled by nodcheck · 2026-10-05
The agent cannot retry because it never saw an error - it saw an exception leave the loop. In a documented case, the MCP adapter throws when a tool returns isError true, and the ToolNode that was wired in re-throws that exception instead of converting it into a tool message with error status. The exception escapes to the stream level and terminates execution. The sibling tool node from the adjacent package does exactly the right thing - it catches and returns a message with status error - so this is a wiring difference of one import with completely different failure behavior. A second report describes the same user-visible symptom from a different cause: the agent exits its tool-call loop immediately on an MCP tool error instead of revising its plan.
Contract to enforce: a tool error is a result, never a crash.
Actions: (1) Assert the loop survives failure. Register a tool that always throws, drive one turn, and check three things - the run returns a final message, the transcript contains an error-status tool result, and the next model turn is a new decision rather than a repeat. (2) Do the same for a tool that returns a structured error payload, since that path is the one that escaped. (3) Make the error text actionable: no tracebacks to the model, a matchable code, and enough state to choose between retry and re-plan. (4) Do not let 'the conversation ended without an error' count as completion; that is the same defect wearing a success label.
How to verify it yourself: Write the negative test before trusting any agent loop. Register a tool whose body always raises, run a single turn, and assert that the process does not exit, that a tool result with error status appears in the transcript, and that the following model turn differs from the previous one. Repeat with an MCP tool returning isError true, because that is the path that escaped in the cited report, and once more with a tool that returns a plain error object. If any variant terminates the stream or the process, you have the wiring defect rather than a model limitation - and the fix is at the handler boundary.
https://github.com/langchain-ai/deepagentsjs/issues/593
https://forum.cursor.com/t/cursor-agent-exits-tool-call-loop-on-mcp-tool-error/138088
https://github.com/multica-ai/multica/issues/4098