Deprecate McpErrorCode.ResourceNotFound (-32002) and use McpErrorCode.InvalidParams (-32602) per SEP-2164#1558
Conversation
…rceNotFound (-32002) and use InvalidParams (-32602) per SEP-2164
|
@mikekistler , can you please help reviewing this. |
|
It seems like we could make this backward compatible if we conditioned the return code value on the protocol version. If the version is "DRAFT-2026-06-v1" (soon to be renamed to the actual spec date, currently expected to be 2026-06-30) or later, the return -32602, and otherwise return -32002. I realize this is going to be more complicated, but it would avoid potentially breaking clients using 2025-11-25 and earlier spec versions. |
…ourceNotFound vs InvalidParams per review
|
@mikekistler, thanks for the review. I was able to add a branching logic looking at the negotiated protocol version. |
| /// </remarks> | ||
| internal static bool UseSep2164ResourceErrors(string? protocolVersion) | ||
| { | ||
| const string MinSep2164ProtocolVersion = "2026-06-30"; |
There was a problem hiding this comment.
Thanks for updating this. Now that #1553 has been merged, you can add this logic to McpHeaders.cs and reference the DRAFT-2026-v1 constant there. We might have to rename the constant to something a little more generic.
| return false; | ||
| } | ||
|
|
||
| return string.Compare(protocolVersion, MinSep2164ProtocolVersion, StringComparison.Ordinal) >= 0; |
There was a problem hiding this comment.
For now, only use the InvalidParams error codes if there's an exact ordinal match with "DRAFT-2026-v1". We shouldn't be doing a >= comparison on strings.
| /// draft string <c>"DRAFT-2026-06-v1"</c> because <c>'D'</c> sorts greater than <c>'2'</c> | ||
| /// in ASCII. | ||
| /// </remarks> | ||
| internal static bool UseSep2164ResourceErrors(string? protocolVersion) |
There was a problem hiding this comment.
| internal static bool UseSep2164ResourceErrors(string? protocolVersion) | |
| internal static bool UseInvalidParamsForMissingResource(string? protocolVersion) |
I think we should remove any mention of "SEP-2164" or SEPs in general from method names and comments. I know it's internal, but the individual SEPs won't matter much after this PR is merged.
| { | ||
| var resource = McpServerResource.Create(options: new() { UriTemplate = uriTemplate }, method: method); | ||
| var client = await CreateClientWithResourcesAsync(resource); | ||
| var client = await CreateClientWithResourcesAndServerVersionAsync("2026-06-30", resource); |
There was a problem hiding this comment.
I don't think we should update the generic "AssertNoMatchAsync" test helper method to use a draft protocol version. That should be explicitly opted into with theory data or at least a literal in the top-level test.
| // Literal template braces in URI should not match (template literal is not a valid URI) | ||
| var mcpEx = await Assert.ThrowsAsync<McpProtocolException>(async () => await client.ReadResourceAsync("test://params{?a1,a2,a3}", null, TestContext.Current.CancellationToken)); | ||
| Assert.Equal(McpErrorCode.ResourceNotFound, mcpEx.ErrorCode); | ||
| Assert.Equal(McpErrorCode.InvalidParams, mcpEx.ErrorCode); |
There was a problem hiding this comment.
Let's not update the generic tests to use the draft protocol version just yet. We can do this later. ResourceNotFound_ErrorCode_IsVersionGated should give us enough coverage for the InvalidParams logic.
4 participants
Fixes #1540
SEP-2164 standardizes the error code for "resource not found" from the MCP-specific
-32002to the standard JSON-RPC-32602(Invalid Params), as part of the 2026-06-30 MCP spec release.How Has This Been Tested?
dotnet test) — no new tests were needed since the existing resource routing, resource builder, and exception propagation tests already cover the error code path; their assertions were updated to expect-32602.Breaking Changes
McpErrorCode.ResourceNotFoundis marked[Obsolete]but retained at its original value-32002for backward compatibility with pre-2026-06-30 clients and servers that may still send or check for that code. New code should useMcpErrorCode.InvalidParams(-32602).Server implementors who currently throw
McpErrorCode.ResourceNotFoundwill see a compiler warning directing them to migrate toMcpErrorCode.InvalidParams.Types of changes
Checklist
Additional context
McpErrorCode.ResourceNotFound = -32002is marked[Obsolete]with a message pointing toInvalidParamsReadResourcehandler inMcpServerImplnow throwsInvalidParamsMcpErrorCode.InvalidParamsdocs updated to list Resources as a covered contextInvalidParams