tools/call has no path to a protocol-level "Server errors" response, even for unhandled exceptions

[hadaromash]

The Tools spec defines two error mechanisms: Protocol Errors (unknown tool, malformed requests, server errors) returned as a JSON-RPC error, and Tool Execution Errors (API failures, input validation, business logic) returned as a normal result with isError: true. "Server errors" is explicitly listed under Protocol Errors.

In McpServer's CallToolRequestSchema handler (server/mcp.js), the entire tool invocation is wrapped in a single try/catch:

catch (error) {
    if (error instanceof McpError) {
        if (error.code === ErrorCode.UrlElicitationRequired) {
            throw error; // escapes as a real protocol error
        }
    }
    return this.createToolError(error instanceof Error ? error.message : String(error));
}

createToolError always returns { content: [...], isError: true }. Every thrown error — regardless of McpError code, regardless of whether it represents a business-level failure or a genuine unhandled/internal exception — is funneled into a Tool Execution Error. The only value that ever escapes this catch and becomes a real JSON-RPC error is McpError with code UrlElicitationRequired, and that's for an unrelated reason (the multi-round-trip input flow).

To Reproduce

server.registerTool("example", { description: "..." }, async () => {
  throw new Error("something actually crashed, unrelated to tool args or business logic");
});

Calling this tool always returns isError: true over a normal (e.g. HTTP 200 on Streamable HTTP) response — never a top-level JSON-RPC error, no matter what's thrown or what code an McpError carries.

Expected behavior
Some way for an error to legitimately escape as a Protocol Error / "Server errors" response, since the spec defines that case explicitly. Right now there's no way to distinguish, at the protocol level, "the tool intentionally reported a failure" from "the handler crashed" — everything becomes isError: true.

Related: #1429 (same catch-all is why raw internal error messages can leak to the client) and #2162 / #1956 (same catch-all also suppresses a protocol-error path for invalid-argument errors specifically). This issue is about the general case — there's no way to reach the spec's "server errors" protocol-error case at all, for any kind of unhandled exception.

[Bubblegunn]

Thanks @hadaromash — I confirmed this on current main: the tool catch converts both a plain Error and ProtocolError(InternalError) into a normal CallToolResult with isError:true, dropping the -32603 protocol error. The same catch overlaps #1429, which is already assigned, so I do not want to duplicate or expand that work.

For #2656, the narrow option is to let non-elicitation ProtocolErrors escape while preserving current plain-error and validation behavior. The broader option would turn unhandled throws into a sanitized -32603, but that requires coordinating the client-visible error API and migration with #1429. I would keep #2162/argument validation out and test stdio + HTTP, intentional isError, validation, elicitation, protocol escape, and redaction.

Which boundary do maintainers prefer, and should #2656 be assigned to me or folded into #1429?