Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-08-26 02:35:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update dotnet-mcp-builder skill to ModelContextProtocol 2.x (#2487)

Browse Source 
* Update dotnet-mcp-builder skill to ModelContextProtocol 2.x

Align the skill with the C# SDK 2.0.0 release and the MCP 2026-07-28
spec: stable line is now 2.x, HttpServerTransportOptions.Stateless
defaults to true, roots/sampling/MCP-channel logging are [Obsolete]
(MCP9005) with the multi-round-trip input_required pattern as the
replacement, discovery-first negotiation (server/discover) supersedes
the initialize handshake, Mcp-Method/Mcp-Name routable headers, raw
structuredContent for non-object results, required Tool.inputSchema,
and the new ModelContextProtocol.Extensions.Tasks and
ModelContextProtocol.Extensions.Apps packages (typed MCP Apps support
replacing the hand-rolled _meta/ui:// pattern on 1.x).

* Address Copilot review: Apps extension accuracy, header scope, capability ownership

- packages.md: the Apps package replaces the manual _meta wiring, not the
  ui:// resource; note the experimental MCPEXP003 diagnostic; label the
  1.x -> 2.0 list as highlights and add the OAuth/SSE runtime changes
  with a pointer to the full release notes.
- transport-http.md: Mcp-Method is on every POST, Mcp-Name only on named
  invocations (tools/call, prompts/get, resources/read) - do not require
  it globally at gateways.
- mcp-apps.md: current MIME type is text/html;profile=mcp-app (skybridge
  is a legacy draft value); document [McpAppUi] + WithMcpApps().
- server-features.md: roots/sampling are client capabilities, only
  logging sits on ServerCapabilities.

* Correct stateful HTTP guidance: 2026-07-28 has no HTTP sessions

Per the official SDK v2 elicitation docs, a server with Stateless=false
refuses the 2026-07-28 revision so dual-path clients fall back to an
initialize-capable revision; ElicitAsync cannot be used on 2026-07-28
Streamable HTTP at all. Reframe stateful HTTP as down-level
compatibility mode and document the multi-round-trip pattern
(InputRequiredException / InputRequest.ForElicitation, retry with
InputResponses -> ElicitResult) as the current-protocol way to ask
mid-tool, across SKILL.md, transport-http.md, and elicitation.md.
This commit is contained in:
Adrien Clerbois
2026-07-31 02:31:14 +02:00
committed by GitHub
parent ed3d68dd66
commit aa01464ccb
13 changed files with 69 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/dotnet-mcp-builder/references/transport-stdio.md
+2 -2
View File
@@ -7,7 +7,7 @@ STDIO is the right choice when the server runs as a child process of the client
- Local-first server (file-system access, dev tools, CLI integrations).
- Distributing as a single executable or a `dnx`-runnable NuGet package.
- You want the simplest possible deployment story (no network, no auth).
- You need server-to-client features (sampling, elicitation, roots) — STDIO always supports them, no `Stateless` flag to worry about.
- You need server-to-client features (elicitation, notifications, the deprecated sampling/roots) — STDIO always supports them, no `Stateless` flag to worry about.
If the user wants a remote/multi-tenant server, use [HTTP Streamable](./transport-http.md) instead.
@@ -65,7 +65,7 @@ The single most common bug in STDIO servers is something writing to stdout that
## Server identity
The SDK sends `serverInfo` (name + version) in the `initialize` response. By default it derives them from your assembly. To override:
The SDK sends `serverInfo` (name + version) during negotiation (the 2026-07-28 `server/discover` exchange, or the legacy `initialize` response for down-level clients — the SDK handles both automatically). By default it derives them from your assembly. To override:
```csharp
builder.Services