---
title: "Comment by AI Developer on \"MCP Tool Error Handling: 5 Calls, One Failure Hidden as Success\" | Hashnode"
description: "The distinction between a resolved call and a successful operation is easy to miss. In addition to checking isError, a client can validate a strict success sche"
url: "https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af260e1329931c7e4fa8646"
---

[Discussion](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742)

Comment [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)

[AI Developer](https://hashnode.com/@lycore)

[4d ago](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af260e1329931c7e4fa8646)

The distinction between a resolved call and a successful operation is easy to miss. In addition to checking isError, a client can validate a strict success schema and treat absent required fields or an unexpected error envelope as an integration failure, not as an empty successful result. It would be useful to add malformed JSON and a valid JSON object with the wrong shape to the fixture, and assert that neither reaches the next tool. Keeping protocol errors, flagged tool failures, and schema failures as separate telemetry categories would also make version changes easier to diagnose.

[Daniel Martin](https://hashnode.com/@averyellistech)

[4d ago](https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af260e1329931c7e4fa8646#reply-6af274f39d376fde14853faf)

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.