Handle requests for capabilty, when capability not present

[johnkors]

Motivation and Context

Some clients ignore the capabilities, and sends <capability>/list requests regardless (ex: Claude Desktop).

ex: Claude Desktop polls for /resources/list even though resources is missing from the capabilities. The C# SDK throws exceptions and logs as ERROR statements. This PR changes this to just return the MethodNotFound error code over JSON-RPC, and log as a warning instead of error.

Relevant discussion: #74 (comment)

How Has This Been Tested?

Use Claude Desktop

• Verify that my server does not log errors when connect to Claude.

Ran all tests

Breaking Changes

No

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 don't have full framework, who does??)
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[halter73]

ensures the server does not log this as an Error log statement

This part seems good. I agree that the server should not emit error logs just because a client is behaving improperly.

notifies the client about the bad request using a notification message, instead of returning an error messages

This seems problematic. Have you tried calling ListResourcesAsync from our client when connected to an MCP server without a list resources capability? I suspect it might hang now that the server no longer produces this JsonRpcError:

csharp-sdk/src/ModelContextProtocol/Shared/McpSession.cs

Lines 159 to 165 in 0c9e91f

	await SendMessageAsync(new JsonRpcError
	{
	Id = request.Id,
	JsonRpc = "2.0",
	Error = detail,
	RelatedTransport = request.RelatedTransport,
	}, cancellationToken).ConfigureAwait(false);

[johnkors]

I suspect it might hang now that the server no longer produces this JsonRpcError:

Ah, ok! Thanks. So it might be better to do respond with an JsonRpcError instead of sending the LoggingMessageNotification then?

I cannot throw, since that's tied together with the problematic error log level.

RelatedTransport seems new, I'll rebase and add that as well.

+++ await SendMessageAsync(new JsonRpcError 
+++ { 
+++     Id = request.Id, 
+++     JsonRpc = "2.0", 
+++     Error = detail, 
+++     RelatedTransport = request.RelatedTransport,  
+++ }, cancellationToken).ConfigureAwait(false); 
--- await _transport.SendMessageAsync(new JsonRpcNotification
---{
---    JsonRpc = "2.0",
---    Method = NotificationMethods.LoggingMessageNotification,
---    Params = new JsonObject
---    {
---        ["message"] = $"{EndpointName} lacks capability to do {request.Method}",
---        ["requestId"] = request.Id.ToString(),
---        ["type"] = nameof(BadRequest)
---    }
---}, cancellationToken).ConfigureAwait(false);
---return;

Have you tried calling ListResourcesAsync from our client when connected to an MCP server without a list resources capability? I suspect it might hang now that the server no longer produces this JsonRpcError

No, I did not do a manual regression test. All automated tests pass when I do dotnet test at least. One unrelated test fail if I run the test suite in Rider, I'll do a PR to make that pass if you want.

[johnkors]

Updated the code to respond with JsonRpcError instead.

[halter73]

How does this surface now if the client calls something like SendRequestAsync or ListResourcesAsync and the capability/handler is missing on a server written with this SDK? Can you add a test verifying what happens makes sense?

[johnkors]

Not sure I can assert that the log level is reduced, but I have not changed any behaviour. Is there a missing test from before, I'll happily add it. Where do you want it?

Before the change:

1. throw ex
2. log Err
3. return JsonRpcError to client

After the change

1. don't throw,
2. log wrn
3. return JsonRpcError to client

[stephentoub]

What does this achieve that's not already achieved when the caller a frame or two up catches the exception and similarly sends back a JsonRpcError?

csharp-sdk/src/ModelContextProtocol/Shared/McpSession.cs

Lines 135 to 166 in e190844

	catch (Exception ex)
	{
	// Only send responses for request errors that aren't user-initiated cancellation.
	bool isUserCancellation =
	ex is OperationCanceledException &&
	!cancellationToken.IsCancellationRequested &&
	combinedCts?.IsCancellationRequested is true;
	if (!isUserCancellation && message is JsonRpcRequest request)
	{
	LogRequestHandlerException(EndpointName, request.Method, ex);
	JsonRpcErrorDetail detail = ex is McpException mcpe ?
	new()
	{
	Code = (int)mcpe.ErrorCode,
	Message = mcpe.Message,
	} :
	new()
	{
	Code = (int)McpErrorCode.InternalError,
	Message = "An error occurred.",
	};
	await SendMessageAsync(new JsonRpcError
	{
	Id = request.Id,
	JsonRpc = "2.0",
	Error = detail,
	RelatedTransport = request.RelatedTransport,
	}, cancellationToken).ConfigureAwait(false);
	}

Is the sole purpose here to avoid an exception try/catch, or are you trying to achieve something else?

[halter73]

I think part of the goal is to get rid of the LogRequestHandlerException warning log, but I agree that instead special-casing McpExceptions with McpErrorCode.MethodNotFound in the existing catch to emit a lower-severity log makes more sense.

[stephentoub]

Before the change:
log Err

Which log is still at the error level?