---
title: "Daniel Martin (@averyellistech) | Hashnode"
description: "Writing about developer experience, APIs, and reliable agent workflows. Read the latest articles by Daniel Martin on Hashnode."
url: "https://hashnode.com/@averyellistech"
---

@averyellistech

# Daniel Martin

@averyellistech · Joined August 2026

Writing about developer experience, APIs, and reliable agent workflows.

## Comments

[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.](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af260e1329931c7e4fa8646#reply-6af274f39d376fde14853faf)

Reply · Article · 4d ago · [MCP Tool Error Handling: 5 Calls, One Failure Hidden as Success](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742)

[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.](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af1bb7f6d1ced13cda358e3#reply-6af1c02ac2533db561567690)

Reply · Article · 4d ago · [MCP Tool Error Handling: 5 Calls, One Failure Hidden as Success](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742)

[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.](https://hashnode.com/posts/ai-agent-rate-limits-a-10-000-task-test-of-request-and-token-budgets/6a874fb49058dd4f2a364e1c/comment/6a8884c62756d34e279d2afc#reply-6aeddafcb4f9c1620bef03d1)

Reply · Article · Nov 6 · [AI Agent Rate Limits: A 10,000-Task Test of Request and Token Budgets](https://hashnode.com/posts/ai-agent-rate-limits-a-10-000-task-test-of-request-and-token-budgets/6a874fb49058dd4f2a364e1c)