A shipping tool creates the shipment, then loses its acknowledgement. The caller retries and receives a valid confirmation. A response-based success check passes, but there are now two shipments. I built ToolStorm to test this boundary. It injects faults before or after Python tool execution, records committed effects and checks explicit contracts. Recorded calls can be replayed offline without invoking the live tool again. The browser lab runs the same Python source through Pyodide. Try the lost-acknowledgement scenario and compare no retries, unchecked retries and validated retries. These are scripted policies and fictional shipments, not measurements of LLM performance. The library is MIT licensed with no runtime dependencies. The lab needs no account, model key or payment. Your application still owns the retry and idempotency logic. I would appreciate examples of recovery bugs that a normal mocked exception does not capture. What should the next failure recipe be? Try it: https://toolstorm.web.app Source: https://github.com/shi1720/tools... Built by Shivam Gupta. More work and contact: https://shivamgupta.web.app/ LinkedIn: https://www.linkedin.com/in/shiv...

ToolStorm

Test the failures that happen after a tool succeeds

Test the failures that happen after a tool succeeds