Haystack Search MCP server fails from .NET client

[AArnott]

Describe the bug

The Haystack Search MCP server works in VS Code and the MCP Inspector, but fails with the .NET MCP SDK:
(https://microsoft.visualstudio.com/Edge/_wiki/wikis/Edge.wiki/201379/Haystack-Search-Empower-your-search-in-VS-Code)

[Haystack Search - Empower your search in VS Code - Overview]

To Reproduce

1. Install the VS Code extension
2. Add the MCP server to VS Code via its http://localhost:13135/mcp/sse endpoint.
3. Confirm that VS Code discovered 2 tools.
   
4. Check out the MCP Inspector which also verifies two tools:
   
5. Now try with the .NET MCP SDK:

var transport = new SseClientTransport(new SseClientTransportOptions { Endpoint = new Uri("http://localhost:13135/mcp/sse") });
IMcpClient client = await McpClientFactory.CreateAsync(transport)

Awaiting CreateAsync throws an exception

System.InvalidOperationException
  HResult=0x80131509
  Message=Failed to send message
  Source=ModelContextProtocol
  StackTrace:
   at ModelContextProtocol.Client.SseClientSessionTransport.<SendMessageAsync>d__10.MoveNext()
   at ModelContextProtocol.McpSession.<SendRequestAsync>d__28.MoveNext()
   at ModelContextProtocol.McpEndpointExtensions.<SendRequestAsync>d__1`2.MoveNext()
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at ModelContextProtocol.Client.McpClient.<ConnectAsync>d__20.MoveNext()
   at ModelContextProtocol.Client.McpClient.<ConnectAsync>d__20.MoveNext()
   at ModelContextProtocol.Client.McpClientFactory.<CreateAsync>d__0.MoveNext()
   at ModelContextProtocol.Client.McpClientFactory.<CreateAsync>d__0.MoveNext()
   at Microsoft.VisualStudio.Conversations.Service.Mcp.McpServerTracker.<>c__DisplayClass8_0.<<-ctor>b__0>d.MoveNext() in Q:\source\VisualStudio.Conversations\src\Copilot.Service\Mcp\McpServerTracker.cs:line 57

  This exception was originally thrown at this call stack:
    ModelContextProtocol.Client.SseClientSessionTransport.SendMessageAsync(ModelContextProtocol.Protocol.JsonRpcMessage, System.Threading.CancellationToken)
    ModelContextProtocol.McpSession.SendRequestAsync(ModelContextProtocol.Protocol.JsonRpcRequest, System.Threading.CancellationToken)
    ModelContextProtocol.Client.McpClient.ConnectAsync(System.Threading.CancellationToken)
    ModelContextProtocol.Client.McpClient.ConnectAsync(System.Threading.CancellationToken)
    ModelContextProtocol.Client.McpClientFactory.CreateAsync(ModelContextProtocol.Client.IClientTransport, ModelContextProtocol.Client.McpClientOptions, Microsoft.Extensions.Logging.ILoggerFactory, System.Threading.CancellationToken)
    ModelContextProtocol.Client.McpClientFactory.CreateAsync(ModelContextProtocol.Client.IClientTransport, ModelContextProtocol.Client.McpClientOptions, Microsoft.Extensions.Logging.ILoggerFactory, System.Threading.CancellationToken)
    Microsoft.VisualStudio.Conversations.Service.Mcp.McpServerTracker..ctor.AnonymousMethod__0() in McpServerTracker.cs

Expected behavior

The connection succeeds. No exception thrown.

Additional context

Note this server is SSE -- Not "streamable HTTP". The Inspector fails when on "streamable HTTP". SSE mode seems to be the default for the .NET MCP SDK, so I expect this to work.

[AArnott]

@halter73

[halter73]

I downloaded the extension and see that we're throwing the spectacularly unhelpful "Failed to send message" InvalidOperationException because the server is responding to the POST request with unexpected JSON. Instead, we expect the response body to be empty or just "Accepted".

csharp-sdk/src/ModelContextProtocol/Client/SseClientSessionTransport.cs

Lines 99 to 115 in ee9b04b

	if (string.IsNullOrEmpty(responseContent) || responseContent.Equals("accepted", StringComparison.OrdinalIgnoreCase))
	{
	LogAcceptedPost(Name, messageId);
	}
	else
	{
	if (_logger.IsEnabled(LogLevel.Trace))
	{
	LogRejectedPostSensitive(Name, messageId, responseContent);
	}
	else
	{
	LogRejectedPost(Name, messageId);
	}
	throw new InvalidOperationException("Failed to send message");
	}

Here's the log (not to excuse the terrible exception):

trce: ModelContextProtocol.Client.SseClientTransport[205728921]
      http://localhost:13135/mcp/sse rejected SSE transport POST for message ID '1'. Server response: '{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"logging":{},"prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},"tools":{}},"serverInfo":{"name":"Haystack","version":"1.3.0"}}}'.

There are several issues with this. The first is I cannot find anywhere in the specification that the response body has to be empty or "Accepted." Maybe this was a requirement at one point, but I cannot find evidence for it. @PederHP Do you know? Our sdk, the typescript sdk, and a few others do send "Accepted" in the response body, but it seems wrong to demand it especially if the MCP Server Inspector does not.

csharp-sdk/src/ModelContextProtocol.AspNetCore/SseHandler.cs

Line 111 in ee9b04b

await context.Response.WriteAsync("Accepted");

[eiriktsarpalis]

If you look at earlier versions of the same check, this would fall back to attempting to deserialize the response directly from the body:

csharp-sdk/src/ModelContextProtocol/Protocol/Transport/SseClientSessionTransport.cs

Lines 117 to 131 in cae5dff

	// If the response is not a JSON-RPC response, it is an SSE message
	if (string.IsNullOrEmpty(responseContent) || responseContent.Equals("accepted", StringComparison.OrdinalIgnoreCase))
	{
	_logger.SSETransportPostAccepted(_endpointName, messageId);
	// The response will arrive as an SSE message
	}
	else
	{
	JsonRpcResponse initializeResponse = JsonSerializer.Deserialize(responseContent, McpJsonUtilities.JsonContext.Default.JsonRpcResponse) ??
	throw new McpTransportException("Failed to initialize client");
	_logger.TransportReceivedMessageParsed(_endpointName, messageId);
	await WriteMessageAsync(initializeResponse, cancellationToken).ConfigureAwait(false);
	_logger.TransportMessageWritten(_endpointName, messageId);
	}

which I presume is also what haystack expects given the response it sends back:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"logging":{},"prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},"tools":{}},"serverInfo":{"name":"Haystack","version":"1.3.0"}}}

This isn't standard per the 2024-11-05 spec, I take it though that many clients do do this. @PederHP might be able to confirm.

[eiriktsarpalis]

@AArnott I just pushed a fix but I believe Haystack just published an update that appears to fix the problem on their side as well.