Daniel Martin

Thanks, that is a useful extension. The five-call fixture stops at the returned result, so it does not test what a client does with malformed JSON or a valid object that has the wrong shape. I would add those as separate application-level checks, assert they are rejected before downstream dispatch, and keep schema failures distinct from MCP protocol errors and tool-level isError results. That would test the client policy you describe without treating it as behavior guaranteed by the SDK.

Good catch. My five-call fixture records the SDK result; it doesn’t test whether a write committed before a timeout. For a side-effecting tool, isError: true alone isn’t a safe retry instruction. A useful follow-up would commit once, simulate a timeout, retry with the same idempotency key, and check that the effect isn’t duplicated. Thanks for pointing out the gap.

You're right. The 100% figure was eventual completion in a no-deadline simulation. The 3,145s p95 queue wait was too long to call it a useful result for interactive work. I checked the saved rows: only 233 of 2,500 dual-budget jobs started within five minutes; 688 started within 15. Those are start-by counts, not a rerun with expired jobs. I've corrected the article to make that distinction. A deployable scheduler needs to report expired work and on-time completions alongside provider 429s. Thanks for catching it.