Local remote mcp fails with vs2026

My local MCP instance running in VS 2026 doesn’t seem to like Cursor Desktop (Windows).

mcp.json contains the following

{

"mcpServers": {

"local-mcp": {

"url": "https://localhost:7296/api/mcp",

"headers": {

"Authorization": "Bearer NOTUSED",

"Content-Type": "application/json"

},

"transport": {

"type": "sse"

}
}
}

}

returns the following in cursor:

2026-07-27 21:12:58.058 [info] [Shared MCP process] stopped connection: user-local-mcp

2026-07-27 21:12:58.065 [info] [Shared MCP process] connecting streamableHttp for “local-mcp” (user-local-mcp)

2026-07-27 21:12:58.065 [info] [Shared MCP process] [V2 FSM] connection:connect_start: conn=idle,auth=unknown → conn=connecting,auth=unknown

2026-07-27 21:12:58.083 [warning] [Shared MCP process] MCP HTTP exchange failed

2026-07-27 21:12:58.084 [warning] [Shared MCP process] Transient error connecting to streamableHttp

Hey, thanks for the detailed log. This looks like a TLS issue, not MCP itself. Your server is running on https://localhost:7296 using the ASP.NET Core dev certificate, and Cursor is dropping the connection during the TLS handshake before it even reaches MCP. That’s why you see MCP HTTP exchange failed within a few milliseconds.

What to try:

  1. Easiest option: run the HTTP launch profile in Visual Studio, like http://localhost:5xxx/api/mcp, instead of HTTPS. Dev certificates are often the cause.
  2. Or trust the dev cert: run dotnet dev-certs https --trust, then fully restart Cursor. Also check that Http: System Certificates and Http: Fetch Additional Support are enabled in settings, both are on by default.
  3. Clean up the config: you can remove the transport block. That’s VS Code syntax, Cursor ignores it and negotiates transport automatically, it tries Streamable HTTP first. Manually setting Content-Type isn’t needed either, it’s set automatically.

If it still fails after that, share the full MCP HTTP exchange failed log line. It should include the underlying error code, like DEPTH_ZERO_SELF_SIGNED_CERT, plus your Cursor version. That should make it clear what’s going on.

For reference, a similar self-signed cert case was discussed here: Can Cursor connect to MCP server with self-signed certificate using streamable-http?

That worked, updated VS2026 and reset to use http

Glad it’s working now. Switching to the HTTP profile really does avoid the self-signed dev certificate issue, it’s the easiest way for a local MCP.

If you later want to switch back to HTTPS, you just need to trust the dev certificate once using dotnet dev-certs https --trust and fully restart Cursor. Let me know if anything starts acting up again.