Fix: Non-existent tool, disabled tool and inputSchema validation return MCP protocol level instead of CallToolResult with isError: true

[KKonstantinov]

Currently, a few scenarios return a MCP protocol level error as opposed to a CallToolResult with isError: true. This leads to MCP hosts (e.g. Claude and others) not being able to read the error message and attempt self-correct.

Affected scenarios:

• Non-existent tool call
• Disabled tool call
• InputSchema validation not passing

Motivation and Context

MCP hosts should be able to attempt self-correct after getting a validation error, or calling a non-existent or disabled tool.

Specification non-conformance

The spec confirms that a CallToolResult should be returned:

Any errors that originate from the tool SHOULD be reported inside the result object, with isError set to true, not as an MCP protocol-level error response. Otherwise, the LLM would not be able to see that an error occurred and self-correct.

https://modelcontextprotocol.io/specification/2025-06-18/schema#calltoolresult

(thanks @cliffhall for finding the right spot in the spec)

Examples of other SDKs not having this issue and following spec

Python SDK is an example that returns a CallToolResult for these scenarios. Code for inputSchema validation returning CallToolResult (isError: true) can be observed at:

https://github.com/modelcontextprotocol/python-sdk/blob/main/src%2Fmcp%2Fserver%2Flowlevel%2Fserver.py#L499

https://github.com/modelcontextprotocol/python-sdk/blob/6c26d087df3406c7da1f85b8ae3c3caeabf7b002/src/mcp/server/lowlevel/server.py#L440

How Has This Been Tested?

Tested the modified server. Unit tests applied/modified to that effect.

Breaking Changes

None. It's fixing a current bug.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[KKonstantinov]

A screenshot of running the "everything server" (https://github.com/modelcontextprotocol/example-remote-server) and doing a test against it.

Edit: The everything server seems to achieve the same end effect, but by going a different route. It itself uses the Server class directly as opposed to the McpServer, and then throws a ZodError directly at https://github.com/modelcontextprotocol/example-remote-server/blob/a02624c8b558d42e0fbccf710e7e2dbd581e1fc2/src/modules/mcp/services/mcp.ts#L473 .

It is then caught by the Protocol class general catch block at

typescript-sdk/src/shared/protocol.ts

Line 394 in 5a8fb39

return capturedTransport?.send({

.

---

TL;DR the everything server likely needs an issue fix on its own since it's not using McpServer.

[KKonstantinov]

Cc @pcarleton

Was thinking - the conformance suite you raised few weeks back would immediately catch exactly things like this and this issue underwrites the need for such a suite even more.

[felixweinberger]

Thanks for this, makes sense to me - just think we should also move the output validation into the code block (+ tests covering that) into the try-catch block while we're at it for SDK consistency.