---
title: "Comment by Kartik N V J K on \"MCP Tool Error Handling: 5 Calls, One Failure Hidden as Success\" | Hashnode"
description: "I did not expect the unknown-tool row. The spec describes it as a JSON-RPC protocol error, and your SDK 1.26.0 fixture got a resolved result carrying isError tr"
url: "https://hashnode.com/posts/mcp-tool-error-handling-5-calls-one-failure-hidden-as-success/6af181e5dca8f65f12d06742/comment/6af3554df452f9a8a3de40d1"
---

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

[Kartik N V J K](https://hashnode.com/@kartik-nvj)

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

I did not expect the unknown-tool row. The spec describes it as a JSON-RPC protocol error, and your SDK 1.26.0 fixture got a resolved result carrying isError true instead, so the split I was treating as reliable, protocol rejection versus tool failure, depends on the SDK version. I hit something similar chasing retry behavior across MCP servers, so a pinned version-specific test reads like the only safe answer.