deps: Bump ModelContextProtocol.AspNetCore from 1.0.0 to 2.1.0 - #11
Open
dependabot[bot] wants to merge 1 commit into
Open
deps: Bump ModelContextProtocol.AspNetCore from 1.0.0 to 2.1.0#11dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
--- updated-dependencies: - dependency-name: ModelContextProtocol.AspNetCore dependency-version: 2.1.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated ModelContextProtocol.AspNetCore from 1.0.0 to 2.1.0.
Release notes
Sourced from ModelContextProtocol.AspNetCore's releases.
2.1.0
This release adds an opt-in
subscriptions/listenhandler for custom server-side notification streams, improves HTTP transport fallback reliability, and expands guidance and samples for telemetry and binary resources.What's Changed
Documentation Updates
Test Improvements
Repository Infrastructure Updates
> [!NOTE]alert example #1771 by @PranavSenthilnathan (co-authored by @Copilot)Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0...v2.1.0
2.0.0
Version 2.0.0 brings the C# SDK into stable alignment with the MCP 2026-07-28 specification.
This major release introduces discovery-first negotiation, multi-round-trip requests, stateless-by-default HTTP, caching hints, standardized headers, stronger OAuth and token-cache safety, and dedicated MCP Apps and Tasks extension packages, with down-level interoperability for peers negotiating 2025-11-25 and earlier. Review the migration guidance below.
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
HttpServerTransportOptions.Statelessnow defaults totrue. Stateless servers do not create transport sessions, expose the standalone SSEGET/DELETEendpoints, or support unsolicited server-to-client requests.Stateless = falsewhen an existing server requires legacy stateful behavior. Stateful-only options now produceMCP9006warnings and apply only to down-level initialize-handshake connections.server/discoverfirst and automatically fall back to the legacyinitializehandshake for down-level servers.MCP9005warnings because these features are deprecated by the 2026-07-28 specification.MCP9005temporarily if continued use is required while planning migration.ModelContextProtocol.Extensions.Tasks#1693ModelContextProtocol.Extensions.Tasks, import its namespace, register Tasks withWithTasks(...), and replace CoreRequestMethods.Tasks*constants withTasksProtocolmembers.AuthorizationRedirectDelegateandClientOAuthOptions.AuthorizationRedirectDelegatenow produceMCP9007warnings. Migrate toClientOAuthOptions.AuthorizationCallbackHandlerso callbacks can return the authorization code, state, and issuer.UseStructuredContent = trueand a non-object return type now emit the raw value and matching schema, such asstructuredContent: 72, instead of wrapping it as{ "result": 72 }.resultproperty.Tool.inputSchemaduring deserialization #1600Toolpayload withoutinputSchemanow throwsJsonExceptioninstead of silently defaulting the schema.inputSchema; an empty{}is sufficient.S256incode_challenge_methods_supported.application_typeduring dynamic client registration #1613application_type.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the inferred value is not appropriate.HttpRequestException,TimeoutException, or genuine I/O exception instead of always wrapping failures inIOException.IOException("Failed to connect transport.")wrapper. In AutoDetect mode, inspect the outerHttpRequestExceptionand its inner SSE failure.insufficient_scopechallenge that introduces no new scopes now throwsMcpExceptioninstead of retrying indefinitely.What's Changed
InheritEnvironmentVariablestoStdioClientTransportOptions#1563 by @halter73offline_accessto authorization scope when advertised (SEP-2207) #1479 by @stephentoub (co-authored by @Copilot)McpErrorCode.ResourceNotFoundper SEP-2164 #1558 by @jayaraman-venkatesanMcpClienttool cache #1590 by @tarekghScopeSelectorDelegateto OAuth options #1596 by @halllo... (truncated)
2.0.0-rc.2
This second 2.0 release candidate advances the SDK’s
2026-07-28protocol support, expands Tasks extension conformance tests, strengthens OAuth and transport behavior, and expands 2.0 guidance ahead of general availability.Thank you to the community for using the preview and release-candidate builds and for sharing feedback and issue reports that shape this release!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking-change policies.
DiscoverResult.ServerInfois removed; read and deserializeMeta[MetaKeys.ServerInfo]instead.2026-07-28, replace legacy initialization, ping, logging, and resource-subscription methods withserver/discover,_metalog level, andsubscriptions/listen.statethroughAuthorizationResult.State, and should returnCode,State, andIss.IOExceptionwrapper.What's Changed
Documentation Updates
Test Improvements
_meta.uiserialization round-trip tests #1698 by @yayayouyouRepository Infrastructure Updates
... (truncated)
2.0.0-rc.1
2.0.0-rc.1 advances the v2 SDK toward general availability with stronger OAuth conformance, improved dynamic client registration, and expanded Tasks validation.
We remain on-track to release 2.0.0 stable on or before 2026-07-28.
We want to give a big thanks to @KubaZ2 for reporting the critical, ship-stopping Tasks/HTTP defect in #1720, fixed by #1722!
Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
Remove the preview task-scope helper #1722
McpTasksServerExtensions.CreateMcpTaskScope(...)was removed from the stable surface. This affects only applications built against the v2 preview API; no stable 2.0 release has shipped.Harden OAuth issuer validation #1605
AuthorizationRedirectDelegatenow producesMCP9007, which breaks warning-as-error builds; the manual authorization flow now requires the complete redirect URL.AuthorizationCallbackHandlerand returnAuthorizationResult.Require advertised PKCE S256 support #1700
code_challenge_methods_supported: ["S256"]now cause authentication to fail instead of receiving an inferred default.Send Dynamic Client Registration application types #1613
ApplicationTypenow sends an inferredapplication_typeinstead of omitting it.DynamicClientRegistrationOptions.ApplicationTypeexplicitly when the authorization server requires another value.What's Changed
application_typein Dynamic Client Registration requests #1613 by @jayaraman-venkatesan (co-authored by @Copilot)ClientOAuthProvider#1605 by @mikekistler (co-authored by @halter73 @Copilot)Documentation Updates
release/1.x(v1.4.1) andmain(v2 preview) content #1727 by @jeffhandley (co-authored by @Copilot)Test Improvements
... (truncated)
2.0.0-preview.3
This preview reorganizes the Tasks feature into its own
ModelContextProtocol.Extensions.Taskspackage, keepingModelContextProtocol.Corefocused on the base protocol while a new generic request-handler and alternate-result surface lets the Tasks package layer on top. It also delivers correctness fixes to the draft2026-07-28protocol -- per-request client capabilities, negotiation boundaries, and theresultTypediscriminator -- plus Streamable HTTP client improvements (an empty-JSON-response fix and a new standalone GET-stream opt-out) and conformance-test consolidation.Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
ModelContextProtocol.Extensions.Taskspackage #1693McpTaskStatus,IMcpTaskStore/InMemoryMcpTaskStore, thetasks/*request methods, and the clientGetTaskAsync/UpdateTaskAsync/CancelTaskAsync/CallToolRawAsyncmethods -- is removed fromModelContextProtocol.Coreand relocated to the newModelContextProtocol.Extensions.Taskspackage under theModelContextProtocol.Extensions.Tasksnamespace.ResultOrAlternate<T>(replacingResultOrCreatedTask<T>) plus generic extension points --McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that the Tasks package builds on.PackageReferencetoModelContextProtocol.Extensions.Tasks; changeusing ModelContextProtocol.Protocol;tousing ModelContextProtocol.Extensions.Tasks;for task types; the task client/server APIs are now extension methods (McpTasksClientExtensions/McpTasksServerExtensions), and the task store is registered via the new builder extensions instead ofMcpServerOptions.TaskStore.Experimental APIs
To support extracting Tasks (#1693),
ModelContextProtocol.Coregained a generic server-extension surface --ResultOrAlternate<T>,McpServerRequestHandler,McpServerOptions.RequestHandlers,McpServerHandlers.CallToolWithAlternateHandler,McpRequestFilters.CallToolWithAlternateFilters, andMcpServer.InterceptOutgoingRequests-- that lets extension packages such asModelContextProtocol.Extensions.Taskslayer behavior onto the server pipeline. These APIs are annotated[Experimental]under diagnostic IDMCPEXP002.This surface is still being designed: #1704 tracks composing these seams with the normal filter and subscription pipeline (typed custom RPCs, filter composition, and extension-defined subscriptions). Expect these low-level extensibility APIs to change and potentially remain
[Experimental]through the 2.0.0 stable release.What's Changed
ModelContextProtocol.Extensions.Tasksextension package #1693 by @jeffhandley (co-authored by @Copilot)Test Improvements
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.2...v2.0.0-preview.3
2.0.0-preview.2
This second preview of the 2.0.0 series advances the SDK's alignment with the upcoming
2026-07-28MCP protocol revision: it adds client-side conformance diagnostics for the SEP-2549 caching hints, makes Streamable HTTP error responses echo the request id per the base protocol and SEP-2243, and fully stabilizes now-stable protocol properties so consumer-defined source generators serialize them correctly. Separately -- and unrelated to the protocol revision -- it introducesDeferChangedEvents()onMcpServerPrimitiveCollection<T>for batchinglist_changednotifications when registering primitives in bulk. There are no breaking changes relative tov2.0.0-preview.1.What's Changed
Documentation Updates
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v2.0.0-preview.1...v2.0.0-preview.2
2.0.0-preview.1
This is the first preview of the C# MCP SDK 2.0.0, designed for alignment with the 2026-07-28 MCP specification release. The SDK implements the
2026-07-28protocol version which fundamentally changes how clients and servers interact -- removing theinitializehandshake (SEP-2575), eliminating server-side session state (SEP-2567), introducing Multi Round-Trip Requests (SEP-2322), and deprecating legacy capabilities in favor of the new extensions framework (SEP-2133).The 2.0.0 SDK is fully backward-compatible with servers and clients using the previous
2024-11-05protocol version. Clients automatically negotiate down to the legacyinitializehandshake when connecting to older servers, and servers continue to acceptinitializerequests from older clients. API breaking changes in 2.0.0 are limited to two categories: (1) APIs for capabilities deprecated by the new specification (Roots, Sampling, and Logging), which are now marked[Obsolete]with guidance toward their replacements, and (2) experimental APIs whose contracts changed as the specifications were finalized. Stable, non-deprecated APIs from 1.x continue to work without modification.Protocol Version Negotiation and Handshake Behavior
The 2.0.0 SDK introduces a fundamentally new connection lifecycle:
Default behavior (no configuration needed):
server/discoverrequest withMCP-Protocol-Version: 2026-07-282026-07-28protocol version, it responds with capabilities -- no handshake, no sessionMcpClientOptions.DiscoverProbeTimeout), the client automatically falls back to the legacyinitializehandshake with2025-11-25-32022UnsupportedProtocolVersion,-32021MissingRequiredClientCapability,-32020HeaderMismatch) are never treated as legacy indicators and are surfaced as errorsOpting out of the
2026-07-28protocol version:McpClientOptions.ProtocolVersion = "2025-11-25"to force the legacyinitializehandshake and disable the automatic fallback (a non-nullProtocolVersionnow acts as both the requested version and the minimum the client accepts)Per-request metadata (
2026-07-28protocol version):_metawithio.modelcontextprotocol/protocolVersion,io.modelcontextprotocol/clientInfo, andio.modelcontextprotocol/clientCapabilities2026-07-28 Spec Alignment: SEP Implementation Status
The 2026-07-28 specification release includes 22 SEPs. The table below summarizes C# SDK status. Remaining work is tracked in the 2026-07-28 Spec Compliance milestone.
1.4.1
This release backports a memory-leak fix for HTTP/SSE-based MCP servers.
StreamableHttpServerTransportnow releases its Server-Sent Events response stream reference as soon as a GET request ends, instead of holding it until the session is disposed via explicit DELETE or idle timeout. Long-lived SSE clients that disconnect without sending DELETE no longer pin the underlying Kestrel connection and its associated memory-pool buffers (~20 MiB per session), preventing the sustained memory growth that could accumulate under connect/disconnect churn.What's Changed
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v1.4.0...v1.4.1
1.4.0
v1.4.0 introduces support for the Identity Assertion Authorization Grant (ID-JAG) flow via the new
IdentityAssertionGrantProvider, enabling enterprise SSO scenarios where users authenticate once via their enterprise Identity Provider and access MCP servers without per-server authorization prompts. The release also adds a newInheritEnvironmentVariablesoption onStdioClientTransportOptionsfor controlling the child server's environment, alongside two security hardening fixes: the stdio client transport no longer enumerates child-process environment variables in Trace logs, andDELETEon a Streamable HTTP session now requires the same authenticated user that initiated the session.What's Changed
InheritEnvironmentVariablestoStdioClientTransportOptions#1563 by @halter73 (co-authored by @Copilot)HandleDeleteRequestAsyncnow mirrors theHasSameUserIdcheck already enforced on GET and POST. ADELETEwith a validMcp-Session-Idbut a different authenticated user now returns403 Forbiddeninstead of terminating the session — defense-in-depth against a leaked session ID being used to DoS the original owner.IdentityAssertionGrantProviderand supporting option/response types inModelContextProtocol.Authenticationimplementing the Identity Assertion Authorization Grant flow: RFC 8693 token exchange at the enterprise IdP (ID Token → JWT Authorization Grant) followed by RFC 7523 JWT bearer grant at the MCP authorization server (JAG → access token). See the new Cross-Application Access section in the transport docs for full usage details.Documentation Updates
Repository Infrastructure Updates
Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v1.3.0...v1.4.0
1.3.0
v1.3.0 focuses on improved transport diagnostics and security-focused documentation. The new public
ClientTransportClosedExceptiongives stdio and HTTP clients structured access to transport closure details (exit codes, process IDs, stderr tails, HTTP status codes) without parsing exception messages. Two reliability fixes harden the stdio process pipeline (preventing host crashes from userStandardErrorLinescallbacks) and correct the stateless HTTP transport's capability advertisement. New conceptual documentation covers role/identity propagation in tool execution, allowed-hosts and CORS guidance for HTTP servers, and aligns the docs information architecture with the MCP specification structure.What's Changed
ClientTransportClosedExceptionpublic and unify transport exception handling #1467 by @stephentoub (co-authored by @halter73 @Copilot)McpClient.CreateAsync(...)now surface asIOException(the newClientTransportClosedExceptionderives fromIOException) rather thanInvalidOperationException. Caller-triggeredOperationCanceledExceptionis also no longer wrapped, matching standard async cancellation semantics.Documentation Updates
Test Improvements
Repository Infrastructure Updates
... (truncated)
1.2.0
This release improves stateless HTTP transport defaults and documentation with a breaking behavioral change that we are considering as a server reliability fix and therefore not bumping the major version with this release. Legacy SSE endpoints are now disabled by default with a new
HttpServerTransportOptions.EnableLegacySseproperty available to opt back into responding to the SSE endpoints; the property is marked as an[Obsolete]warning as we expect to remove this property in a future major version.A warning-level
[Obsolete]attribute is also applied to theRequestContext(McpServer, JsonRpcRequest)constructor, and theRequestContext(McpServer, JsonRpcRequest, TParams)overload should be used instead. This change contributes to fixes including DI scope lifetime in task-augmented tools, meta/progress combination failures, and outgoing message filter routing. We plan to remove the obsolete overload in a future major version.Breaking Changes
Refer to the C# SDK Versioning documentation for details on versioning and breaking change policies.
1. Disable legacy SSE by default #1468
MapMcp()no longer maps/sseand/messageendpoints by default. Servers whose clients connect via SSE will find those endpoints removed.Migrating from legacy SSE
If your clients connect to a
/sseendpoint (e.g.,https://my-server.example.com/sse), they were using the legacy SSE transport--if not running inStatelessmode. The/sseand/messageendpoints are now disabled by default (EnableLegacySseisfalseand marked[Obsolete]with diagnosticMCP9004). Upgrading the server SDK without updating clients will break SSE connections.Client-side migration. Change the client
Endpointfrom the/ssepath to the root MCP endpoint — the same URL your server passes toMapMcp(). For example:With the default
HttpTransportMode.AutoDetecttransport mode, the client automatically tries Streamable HTTP first. You can also setTransportMode = HttpTransportMode.StreamableHttpexplicitly if you know the server supports it.Server-side migration. If you previously relied on
/ssebeing mapped automatically, you now needEnableLegacySse = true(suppressing theMCP9004warning) to keep serving those endpoints. The recommended path is to migrate all clients to Streamable HTTP and then removeEnableLegacySse.Transition period. If some clients still need SSE while others have already migrated to Streamable HTTP, set
EnableLegacySse = truewithStateless = false. Both transports are served simultaneously byMapMcp()— Streamable HTTP on the root endpoint and SSE on/sseand/message. Once all clients have migrated, removeEnableLegacySseand optionally switch toStateless = true.SSE (legacy — opt-in only)
Legacy SSE endpoints are now disabled by default and must be explicitly enabled via
HttpServerTransportOptions.EnableLegacySse. This is the primary reason they are disabled — the SSE transport has no built-in HTTP-level backpressure.The legacy SSE transport separates the request and response channels: clients POST JSON-RPC messages to
/messageand receive responses through a long-lived GET SSE stream on/sse. The POST endpoint returns 202 Accepted immediately after queuing the message — it does not wait for the handler to complete. This means there is no HTTP-level backpressure on handler concurrency, because each POST frees its connection immediately regardless of how long the handler runs.Internally, handlers are dispatched with a fire-and-forget pattern. A client can send unlimited POST requests to
/messagewhile keeping the GET stream open, and each one spawns a concurrent handler with no built-in limit.The GET stream does provide session lifetime bounds: handler cancellation tokens are linked to the GET request's
HttpContext.RequestAborted, so when the client disconnects the SSE stream, all in-flight handlers are cancelled. This is similar to SignalR's connection-bound lifetime model — but unlike SignalR, there is no per-client concurrency limit likeMaximumParallelInvocationsPerClient. The GET stream provides cleanup on disconnect, not rate-limiting during the connection.2. Obsolete 2-arg RequestContext constructor #1462
The
RequestContext(McpServer, JsonRpcRequest)constructor is now[Obsolete]with diagnosticMCP9003, producing build warnings. TheParamsproperty is also changed fromTParams?toTParams.Migration: Use the new 3-arg constructor:
new RequestContext(server, request, parameters).What's Changed
... (truncated)
1.1.0
Highlights of v1.1.0 include client completion details for understanding when and why a client connection ended, auto-populated completion handlers from
AllowedValuesAttribute, and bug fixes for server-initiated ping handling, server capabilities initialization, and in-flight message handler cleanup.What's Changed
Documentation Updates
Repository Infrastructure Updates
EnablePackageValidationfor all src packages with1.0.0baseline #1330 by @jeffhandley (co-authored by @Copilot @stephentoub)Acknowledgements
Full Changelog: modelcontextprotocol/csharp-sdk@v1.0.0...v1.1.0
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)