MCP C# SDK 2.0 for a .NET client: check the protocol header with Sume

The C# MCP SDK 2.0 targets the 2026-07-28 spec and keeps 1.x APIs compiling. What to test before pointing a .NET client at Sume, which lists 2025 versions.

3 min readSume
All posts

Before you move a .NET MCP client to the C# SDK 2.0, test one call against Sume and read the status code. The Microsoft .NET blog says the SDK implements the 2026-07-28 revision, which drops the initialize / initialized handshake and sends the protocol version and capabilities with each request. Sume's hosted server lists three protocol versions, 2025-03-26, 2025-06-18 and 2025-11-25, and answers 400 with Unsupported MCP protocol version. when a request's Mcp-Protocol-Version header is outside that list.

So the question is not whether your code compiles. The blog promises that stable, non-deprecated 1.x APIs continue to compile and run in 2.0. The question is which protocol version the client sends on the wire.

What each side says

Sume's side comes from the server source and its health response; the SDK side from the announcement.

C# SDK 2.0 against Sume's endpoint (read 2026-10-08)
ItemSDK 2.0 announcementSume hosted MCP
Spec revision2026-07-28Lists 2025-03-26, 2025-06-18, 2025-11-25
Handshakeinitialize / initialized removedStill answers initialize and reports tools capability
Version headerVersion travels with each requestHeader outside the list gets HTTP 400, JSON-RPC -32600
Client creationMcpClient.CreateAsync with a transport and optionsRemote Streamable HTTP at https://mcp.sume.com/mcp
AuthSDK says auth and authorization are its next focusOAuth mcp:read / mcp:write, or API key as Bearer or x-api-key

Steps to test

Create the client with McpClient.CreateAsync and an HTTP client transport pointed at https://mcp.sume.com/mcp, with an Authorization header carrying your Sume key. Call tools_list first; it is a read call and costs nothing. If you get a 400 with Unsupported MCP protocol version, pin the client to a 2025 version if the SDK lets you, or stay on the 1.x line until Sume lists the newer revision.

  • Log the status code and the response body on the first call, not only the exception message.
  • Use an API key for server-side .NET code; OAuth is for interactive clients.
  • Send an idempotency_key on every write or paid tool, and start with dry_run=true.

Why the status code is the signal

A 400 is a clean failure: the body is a JSON-RPC error with code -32600 and the text Unsupported MCP protocol version. That is easy to tell apart from a 401, which means the credential is wrong, and from a 403 forbidden_origin, which Sume returns when the request's Origin is not allowed. If you only log the exception message from the SDK, those three can look alike, and you may spend an hour rotating a key that was fine.

Write the check as a small console program that makes one call and prints the status. Keep it in your repository so the next SDK bump re-runs it.

What Sume does not do

Sume does not claim support for the 2026-07-28 revision today, and this post cannot say how SDK 2.0 behaves when a server lists only older versions, because the announcement does not cover it. Test it. Sume also does not offer a stateful session you can resume; the endpoint takes POST only, and GET on /mcp returns 405.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume