modelcontextprotocol/csharp-sdk

Version ModelContextProtocol / ModelContextProtocol.AspNetCore 2.1.0 Behavior The SDK applies different JSON property-name casing rules at two levels of the same request: JSON-RPC envelope properties are matched case-sensitively by JsonRpcMessage.Converter (jsonrpc, id, method, params). Method-specific params are deserialized with McpJsonUtilities.DefaultOptions / JsonSerializerDefaults.Web, so DTO property names are accepted case-insensitively. For example, this tools/call request is accepted and dispatches the tool because Name binds to CallToolRequestParams.Name: { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "Name": "search_orders", "arguments": {} } } Changing method to Method or params to Params is rejected by the envelope converter. Why this matters Middleware, gateways, and authorization filters that inspect the JSON-RPC request before SDK dispatch can use exact JSON property lookup based on the envelope converter. They may then fail to rec

Describe the bug Several OAuth tests occasionally fail on the windows-latest legs of Build and Test. If that occurs, the GetAuthServerMetadataAsync method gets a TaskCancelledException during a slow TLS handshake using the in-memory duplex pipe, ClientOAuthProvider wraps that into the "Failed to find .well-known/..." message, and assertion expectations about that message fail on the injected text – that is, the error manifests itself as a confusing assertion failure instead of a timeout. It appears to be similar to #1701 from the OAuth side of things. #1702 increased the server/discover probe timeout in the in-memory tests, but the OAuth metadata path has a similar timeout which was not added and is still failing after that merge. Tests affected so far: OAuth.AuthTests.CannotAuthenticate_WithInvalidClientMetadataDocument OAuth.DcrFailureTests.DcrRejection_PropagatesToConsumer_WithStatusBodyAndSentParameters ClientConformanceTests.RunConformanceTest(scenario: "auth/offline-access-sco

@modelcontextprotocol/inspector successfully connected to the server but tool call failed as the request timed out. It's a simple Echo tool. There is no log both in the application and the @modelcontextprotocol/inspector Log tab. The MCP server is ASP.Net Core 10 deployed and run on local k8s. When I try from Postman, connection is successful but there is no tool found on the server.

How to perform E2E integration tests for MCP server with streaming HTTP transport like what's done for the MVC? Any doc / blog on that?

Describe the bug Registering a handler of the notifications/tools/list_changed method (both via the McpClientOptions.Handlers.NotificationHandlers and via the McpSession.RegisterNotificationHandler(...) method) on a client that is connected to a server over Streamable HTTP works only for ca. 2-3 minutes after creation. If no notification is sent by the server for a longer time, the handler is no longer invoked. The problem does not happen while a debugger is attached. I have validated that the notifications continue to be received by the MCP Inspector, when it is connected at the same time as my client. I assume that an HTTP connection is being dropped somewhere along the way, but I haven't found the root cause yet. Steps To Reproduce Set up an ASP.NET MCP Server as shown in the samples. Have the server send sporadic notifications/tools/list_changed to all connected clients. Connect an MCP Client via Streamable HTTP as shown in the samples. Launch both applications without a debugger