modelcontextprotocol/csharp-sdk
Watch
1
0
Fork
You've already forked csharp-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

Refine 2.0.0 concept documentation (#1742)

Browse source 
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 782b5bad-4046-49ec-93a6-72768b5b7521
Copilot-Session: 4b938335-418c-4ee7-8287-6c70d9148b89
This commit is contained in:
Jeff Handley 2026-07-27 20:15:16 -07:00 • committed by GitHub
commit 314bdb2f49
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 178 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

38
docs/concepts/tasks/tasks.md
View file

@ -14,25 +14,6 @@ Tasks are provided by the `ModelContextProtocol.Extensions.Tasks` package and re
version `2026-07-28` or later. The implementation follows
[SEP-2663 (Tasks Extension)](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2663-tasks-extension.md).
### Compatibility with v1 experimental Tasks
The Tasks extension in v2.0.0 replaces the experimental Tasks implementation shipped in v1.3.0 and
v1.4.x. The implementations are not compatible at either the API or protocol level. A v2 Tasks
client or server must use a connection negotiated to `2026-07-28` or later; it cannot fall back to
the down-level implementation.
On a connection negotiated to the down-level `2025-11-25` protocol:
- A v2 client calling a v1 server receives an ordinary tool result. The v2 client does not opt in
to the down-level Tasks protocol, and `GetTaskAsync` rejects use before a `2026-07-28`
connection is negotiated.
- A v1 client calling a v2 server likewise receives an ordinary tool result. The v2 server does
not create Tasks on a down-level connection, and its `tasks/get` endpoint rejects the legacy
request with a method-not-found error.
Upgrade both peers to the v2 Tasks extension before using Tasks. The extension provides no
compatibility bridge for the previous experimental API.
### Overview
A client opts into tasks on a per-request basis by including the `io.modelcontextprotocol/tasks`
@ -346,6 +327,25 @@ scope, the SDK intentionally skips the normal client-capability negotiation chec
the client opted in by including the extension marker in the originating request, so it's
responsible for handling — or rejecting — the input requests surfaced through `tasks/get`.
#### Compatibility with v1 experimental Tasks
The Tasks extension in v2.0.0 replaces the experimental Tasks implementation shipped in v1.3.0 and
v1.4.x. The implementations are not compatible at either the API or protocol level. A v2 Tasks
client or server must use a connection negotiated to `2026-07-28` or later; it cannot fall back to
the down-level implementation.
On a connection negotiated to the down-level `2025-11-25` protocol:
- A v2 client calling a v1 server receives an ordinary tool result. The v2 client does not opt in
to the down-level Tasks protocol, and `GetTaskAsync` rejects use before a `2026-07-28`
connection is negotiated.
- A v1 client calling a v2 server likewise receives an ordinary tool result. The v2 server does
not create Tasks on a down-level connection, and its `tasks/get` endpoint rejects the legacy
request with a method-not-found error.
Upgrade both peers to the v2 Tasks extension before using Tasks. The extension provides no
compatibility bridge for the previous experimental API.
### Known limitations
- **Server-push task status notifications (SEP-2575)**: not yet implemented. Clients rely on