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
2 changed files with 178 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

2
samples/TasksExtension/Program.cs
View file

@ -24,9 +24,9 @@ var store = new InMemoryMcpTaskStore { DefaultPollIntervalMs = 250 };
var services = new ServiceCollection();
services.AddMcpServer()
.WithStreamServerTransport(clientToServerPipe.Reader.AsStream(), serverToClientPipe.Writer.AsStream())
.WithTools([McpServerTool.Create(SlowTools.RunReport, new() { Name = "run-report" })])
.WithTasks(store);
services.AddSingleton<ITransport>(new StreamServerTransport(clientToServerPipe.Reader.AsStream(), serverToClientPipe.Writer.AsStream()));
await using var serviceProvider = services.BuildServiceProvider();
var server = serviceProvider.GetRequiredService<McpServer>();

25
samples/TasksExtension/README.md
View file

@ -6,16 +6,12 @@ The server is configured with an in-memory `IMcpTaskStore`, which is sufficient
`[McpServerTool]` method automatically run as a background task when the client opts into the
tasks extension on a per-request basis.
The client invokes the same `run-report` tool two ways:
1. **`CallToolAsync` (auto-poll)** — the SDK injects the opt-in marker into `_meta`, polls
`tasks/get` at the cadence the server suggests, dispatches any input requests through
registered handlers, and returns the final `CallToolResult` (or throws on a terminal
`Failed`/`Cancelled`).
2. **`CallToolRawAsync` (manual poll)** — the caller receives the raw
`ResultOrCreatedTask<CallToolResult>` and drives the lifecycle directly with
`GetTaskAsync`, `UpdateTaskAsync`, and `CancelTaskAsync`. Useful when you need to surface
progress to a UI or stream task status updates between polls.
The client invokes the `run-report` tool with **`CallToolAsTaskAsync` (manual poll)**. It
receives a `ResultOrCreatedTask<CallToolResult>` and, when the server runs the call as a
background task, drives the lifecycle directly with `GetTaskAsync` — polling at the server's
suggested cadence until the task reaches a terminal state (`Completed`, `Failed`, or
`Cancelled`). If the server returns an inline result instead of creating a task, the sample
surfaces that result and stops.
Both ends of the conversation are connected in-process over an in-memory `Pipe`, so no separate
server process or HTTP transport is required.
@ -29,10 +25,7 @@ dotnet run --project samples/TasksExtension/TasksExtension.csproj
Expected output:
```
=== CallToolAsync (auto-poll) ===
result: report ready
=== CallToolRawAsync (manual poll) ===
=== CallToolAsTaskAsync (manual poll) ===
task created: id=… status=Working pollIntervalMs=250
poll 1: still working …
…
@ -41,10 +34,6 @@ Expected output:
## Notes
- The `MCPEXP001` warning is suppressed because the tasks extension is still experimental. The
project's `<NoWarn>` already includes it; if you copy this pattern into your own project,
either suppress the diagnostic or wrap the experimental APIs in
`#pragma warning disable MCPEXP001`.
- For production deployments — especially stateless HTTP servers — implement
`IMcpTaskStore` against durable storage and register it as a singleton (see
[docs/concepts/tasks/tasks.md](../../docs/concepts/tasks/tasks.md) for the contract).