Good catch, looks like a typo, but this change should be made to the draft spec. I don't believe we retroactively update already published specs.

Ah good catch, draft updated as well. I defer to reviewers on whether to keep changes in 2025-06-18, let me know and I'll update as needed.

I agree, this is a typo. The problem is that we a lot of existing code (see https://github.com/search?q=mcp+AND+-32002&type=code) that uses -32002. If we were to change this, clients and servers would have to be able to change this depending on the MCP version. I am inclined to just live with this and not cause existing code to break.

The problem is that we a lot of existing code (see https://github.com/search?q=mcp+AND+-32002&type=code) that uses -32002.

It's worth pointing out that "-32002" is not resource-related in some of those results. For example, "method not allowed", "invalid bearer token", and lamenting -32002 as a bug in the spec (see also #509).

But I agree with your point, and have changed my mind to not supporting publishing this as a doc fix for v2025-06-18.

I still think there may be value in changing this for v2025-11-25 though. @jba, in a code comment you wrote that the jsonrpc2 Go package defines -32002 as "server closing". Could this be a difference of interpretation of the JSON-RPC 2.0 spec? Or is there further evidence that MCP should refrain from using -32000 to -32099?

This issue has made me think we should do more to make schema.ts the source of truth for error codes. To that end, I've opened #1549. Is there interest in something like that?

If we were to change this, clients and servers would have to be able to change this depending on the MCP version. I am inclined to just live with this and not cause existing code to break.

Out of curiosity, are new spec versions not recommended to have breaking changes? I understand the line of thinking of not changing specs that have been finalized and released to not break existing implementations, but the next spec version seems like as good a place as any to fix this. I'm not terribly opinionated on this change (beyond the "nice-to-have" of consistency with how other server capabilities handle similar scenarios), more so interested in understanding what the philosophy behind versioning and breaking changes for the project is.

not supporting publishing this as a doc fix for v2025-06-18.

Update the PR to reflect this.

Out of curiosity, are new spec versions not recommended to have breaking changes? I understand the line of thinking of not changing specs that have been finalized and released to not break existing implementations, but the next spec version seems like as good a place as any to fix this.

New specs are definitely a better place to make breaking changes, but a breaking change is still a breaking change.

There are many clients and servers out there, and not all of them use the SDKs. Also, likely very few of the maintainers of those clients/servers are following the protocol development closely to know when those changes occur. If they miss the breaking change (highly likely) then software may just stop working or become incompatible with different clients/servers.

We still probably need to make breaking changes occasionally, but it's probably a case of picking your battles, i.e. only doing it when there is a large pay-off in doing so. Not an easy problem to solve. See HTTP Referer :)

To add to this, neither the Typescript nor the Python SDK actually return -32002 by default. The Typescript SDK returns -32602 already, whereas the Python SDK actually just returns 0 for a resource error.

Although, both SDKs allow users to raise their own errors and manually specify the return code (unless you're using the Python SDK's FastMCP, then you can't).