Define handling for protocol-incompatible result properties set by applications
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- csharp
- Domain
- api, backend-api-design
Research direction
Start at the shared post-handler boundary and read how McpServerImpl.IsJuly2026OrLaterProtocolRequest resolves RequestContext.JsonRpcRequest.Context.ProtocolVersion and McpServer.NegotiatedProtocolVersion. Compare the proposed policies before selecting one, then trace normal, cacheable, and immediate alternate result emission. Done means the chosen behavior is defined and exact wire-shape tests cover the listed protocol contexts, handlers, filters, and reused result instances.
Written by the indexing model from the issue text.
Description
Summary
PR #1753 fixes #1721 by stopping the SDK from automatically adding the 2026-07-28-only resultType, ttlMs, and cacheScope properties to legacy results. Applications can still set those properties explicitly from handlers or filters, which can produce a wire shape that is invalid for the negotiated protocol version.
We should define and consistently enforce the server behavior for protocol-version-specific result properties supplied by application code.
Protocol detection
The effective protocol version is already available at the shared post-handler boundary:
- Use
RequestContext.JsonRpcRequest.Context.ProtocolVersionfor per-request metadata protocols. - Fall back to
McpServer.NegotiatedProtocolVersionfor stateful sessions. McpServerImpl.IsJuly2026OrLaterProtocolRequestalready implements this resolution.
Possible policies
- Fail the request before serialization with an InternalError and a useful server-side diagnostic. This gives application developers the strongest signal, but turns an otherwise valid client request into an error. Ordinary application exceptions currently produce a generic
"An error occurred."response, so we would also need to decide whether the client receives a specific message. - Strip the unsupported properties and log a warning. This preserves a valid legacy wire shape while making the application misuse visible to server operators.
- Strip the unsupported properties silently. This maximizes compatibility but can hide application bugs.
Scope
The selected policy should:
- Be applied once at a typed response-emission boundary after handlers and filters.
- Cover
Result.ResultTypeand bothICacheableResultproperties. - Cover normal, cacheable, and immediate alternate results.
- Avoid mutating shared response instances in a way that can affect later requests using another protocol version.
- Preserve explicit values and add required defaults for 2026-07-28 and later responses.
- Be extensible to future protocol-version-specific result properties.
Tests
Add exact serialized wire-shape coverage for:
- Legacy handlers and filters that explicitly set each unsupported property.
- 2026-07-28 handlers and filters with explicit values.
- Normal, cacheable, and immediate alternate results.
- Session-negotiated and per-request HTTP protocol contexts.
- Reused or shared result instances across requests with different protocol versions.
- Dominant language
- C#
- Stars
- 4.5k
- Forks
- 814
- Avg merge
- 9d 19h
- Merged PRs (30d)
- 4
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/csharp-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/csharp-sdk#1867 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
modelcontextprotocol/csharp-sdk#1840 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/csharp-sdk#1836 ·
-
enhancement needs confirmation
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
modelcontextprotocol/csharp-sdk#678 · 1 comment ·
-
enhancement needs confirmation P3 ready for work
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/csharp-sdk#515 · 6 comments · 3 reactions ·
All issues in modelcontextprotocol/csharp-sdk
Similar issues
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
ci-failure-cause test-failure
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:auth FE mvp P3
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
klasolsson81/jobbliggaren#1788 ·