A handler that throws McpError produces a double-prefixed message on the client

[chrikrah]

What happens

A request handler that throws McpError produces a message the client shows with the prefix twice.
Reproduced with the SDK alone over InMemoryTransport on 1.24.3, and the code path is unchanged in the
current 1.30.0:

server.setRequestHandler(CallToolRequestSchema, async () => {
  throw new McpError(ErrorCode.MethodNotFound, "Unknown tool: nope");
});
// ...
try { await client.callTool({ arguments: {}, name: "nope" }); }
catch (e) { console.log("client received:", e.message); }

server threw:   MCP error -32601: Unknown tool: nope
client received: MCP error -32601: MCP error -32601: Unknown tool: nope

Why

Three steps, each defensible alone:

1. McpError's constructor calls super(`MCP error ${code}: ${message}`), so .message already carries
   the prefix.
2. The server serialises a thrown error as message: error.message, so the prefix travels inside the
   JSON-RPC error.message field.
3. Protocol._onresponse converts it back with McpError.fromError(response.error.code, response.error.message, response.error.data), whose default branch returns
   new McpError(code, message, data) and prefixes what is already prefixed. I confirmed at runtime that
   this is the path a callTool rejection takes, by counting calls into fromError: exactly one.

_onresponse also holds a new McpError(...) conversion in its _requestResolvers branch, for queued
responses, which double-prefixes for the same reason.

Throwing McpError is the SDK's own mechanism and shared/protocol throws it in several places itself, so
this is the default result rather than a misuse.

What I expected

One prefix. Either the JSON-RPC error.message carries the bare message, or the client stops re-wrapping a
message that already has the prefix.

Not checked

Only InMemoryTransport, and only a callTool rejection. The one branch of fromError that does not take
the default path is UrlElicitationRequired carrying elicitations, which returns
UrlElicitationRequiredError; that class calls super with the same code, so I would expect it to prefix
too, but I did not exercise it.

[pj-workspace]

Confirmed on the published packages with Node 24.19.0: @modelcontextprotocol/sdk@1.30.0 and the v2 client/server packages at 2.0.0. I recorded the server's error response at the public InMemoryTransport.send boundary and checked all four server/client combinations. All negotiated protocol version 2025-11-25.

For the -32601 error in the report:

Server → client	Prefixes in wire error.message	Prefixes in client .message
v1 → v1	1	2
v1 → v2	1	1
v2 → v1	0	1
v2 → v2	0	0

I also exercised the previously unchecked UrlElicitationRequiredError path (-32042): it has the same message behavior, while code, data.elicitations, and the reconstructed specialized error type are preserved. A plain Error control does not acquire a server-side prefix. These checks cover ordinary callTool rejection over in-memory transport, not task-queued responses or HTTP.

#1727 already addressed this in v2 by removing the constructor prefix, replacing #1578's separate wire-message approach. It explicitly identified the local .message change as breaking, so I would not assume the same constructor change is appropriate for v1.

Would a v1.x fix that preserves the locally constructed McpError.message format while serializing the original, unprefixed message be welcome, or would you prefer documenting the v2 behavior here? If a v1 patch is desired, I can work on it with wire/client regression coverage, including URL elicitation, without heuristically stripping text from arbitrary error messages.

[LouisDeconinck]

I'd like to take this. From the trace, the client re-wraps the server's error message when it builds its own McpError, so the MCP error -32601: prefix gets applied twice — I'll look at skipping the prefix when the incoming message already carries one, and cover both branches if the v1/v2 code paths differ.