MCP wird oft als Protokoll diskutiert. Für .NET-Teams ist aber die spannendere Frage: Wie fühlt sich MCP im eigenen Stack an? Genau hier ist das offizielle C# SDK wichtig. Es übersetzt MCP nicht nur in C#-Typen, sondern in vertraute .NET-Konzepte: NuGet-Pakete, Hosting, Dependency Injection, ASP.NET Core, HttpClient, Authentifizierung und Observability.
Das Repo modelcontextprotocol/csharp-sdk beschreibt sich als offizielles SDK für MCP-Clients und MCP-Server in .NET. Zum Zeitpunkt dieses Artikels ist auf GitHub und NuGet die Version 1.4.0 aktuell. Für mich ist daran weniger die Versionsnummer entscheidend als die Richtung: MCP wird nicht als Fremdkörper neben .NET gestellt, sondern in die Plattform eingebettet.
Die drei Pakete sind ein gutes Signal
Mir gefällt, dass das SDK nicht alles in ein Paket wirft. ModelContextProtocol.Core ist für Projekte gedacht, die Client-Funktionalität oder Low-Level-Server-APIs mit wenigen Abhängigkeiten brauchen. ModelContextProtocol ist das Standardpaket für die meisten Anwendungen, inklusive Hosting und Dependency Injection. ModelContextProtocol.AspNetCore ist die Schicht für HTTP-basierte Server.
Diese Aufteilung ist mehr als Paketkosmetik. Sie zeigt, dass MCP in .NET sehr unterschiedliche Formen haben kann: lokaler stdio-Server für ein Coding-Tool, eingebetteter In-Process-Test, remote erreichbarer ASP.NET-Core-Endpunkt oder geschützter Enterprise-Service.
Meine Einordnung: Das C# SDK macht MCP dann interessant, wenn ein Team ohnehin in .NET denkt und seine Agentenfähigkeiten wie normale Plattformkomponenten betreiben will.
Die wichtigsten Features
Der Kern ist erwartbar: Clients können MCP-Server verbinden, Tools listen und Tools aufrufen. Server können Tools, Resources und Prompts bereitstellen. Spannend wird es bei den .NET-spezifischen Details.
McpClient.CreateAsync entsteht ein Client, der Tools, Resources und Prompts eines Servers nutzen kann. Auf der Serverseite werden Fähigkeiten über Attribute wie McpServerTool, McpServerResource oder McpServerPrompt oder über Factory-APIs bereitgestellt.
AddMcpServer, WithHttpTransport und MapMcp fühlen sich wie normale ASP.NET-Core-Bausteine an. Dadurch passen MCP-Endpunkte in bekannte Hosting-, Middleware-, CORS-, Auth- und Observability-Muster.
IChatClient genutzt werden. Dadurch kann ein Chat- oder Agentenclient MCP-Fähigkeiten verwenden, ohne dass jedes Modell oder jeder Anbieter separat verdrahtet werden muss.
Warum das für .NET-Architektur relevant ist
In vielen Unternehmen liegen fachliche Systeme, APIs und Integrationslogik bereits in .NET: interne Services, Background Worker, Web APIs, Azure-nahe Anwendungen, Reporting- oder ERP-Integrationen. Ein MCP-Server kann dort eine kontrollierte Agenten-Schnittstelle bereitstellen, ohne die vorhandene Plattformlogik neu zu erfinden.
Das ist für mich der eigentliche Architekturpunkt. Ein guter MCP-Server ist kein dünnes Fenster auf alle internen APIs. Er ist eine kuratierte Fähigkeitsschicht. In C# kann diese Schicht direkt an vorhandene Services, Policies, Logger, HttpClients, Options und Authentifizierung angebunden werden. Genau dadurch wird MCP weniger Demo und mehr Betriebsmodell.
Die Samples als Lernpfad
Das Repo hat eine erstaunlich breite Sample-Landschaft. Sie ist nicht perfekt als linearer Kurs geschrieben, aber als Landkarte zeigt sie gut, welche Entscheidungen ein echtes MCP-Projekt treffen muss.
Microsoft.Extensions.AI einem Chatclient verfügbar macht.
Wichtig, weil hier sichtbar wird, wie MCP-Tools in eine LLM-Konversation wandern.
McpAppUi, WithMcpApps und strukturierter Ausgabe für eine Wetter-UI.
Spannend, weil MCP hier nicht nur Tool-Aufruf ist, sondern interaktive Oberfläche im Host.
Was ich an der Implementierung stark finde
Die C#-Implementierung trifft eine gute Balance zwischen Protokollnähe und .NET-Komfort. Wer MCP verstehen will, sieht weiterhin die Begriffe des Standards: Tools, Resources, Prompts, Sampling, Elicitation, Transports. Wer .NET-Anwendungen baut, bekommt aber vertraute Einstiegspunkte: Builder, Services, Attribute, Options, HttpClientFactory, Logging und ASP.NET Core.
Besonders wichtig finde ich die klare Trennung der Betriebsformen. Stdio eignet sich für lokale Tools und IDE-nahe Szenarien. HTTP eignet sich für gemeinsam betriebene Server. InMemory eignet sich für Tests oder eingebettete Fälle. Diese Unterscheidung verhindert, dass MCP als ein einziges Deployment-Muster missverstanden wird.
Wo man aufpassen muss
Das SDK nimmt einem nicht die Produktentscheidung ab. Ein Tool mit McpServerTool-Attribut ist noch kein gutes Agentenwerkzeug. Die eigentliche Arbeit bleibt: enge Schemas, klare Berechtigungen, sinnvolle Fehlerbilder, keine ungefilterten Rohdaten, nachvollziehbare Logs und bewusste Grenzen zwischen Lesen, Vorbereiten und Schreiben.
Gerade weil das SDK MCP so leicht in ASP.NET Core bringt, sollte man nicht jeden internen Controller in einen MCP-Server umdeuten. Gute MCP-Server sind fachlich geschnittene Schnittstellen für Agentenarbeit, keine zweite API-Oberfläche für Menschen und Maschinen gleichzeitig.
Mein Fazit
Das offizielle MCP C# SDK ist für mich ein wichtiger Schritt, weil es MCP in eine der stärksten Enterprise-Plattformen bringt. Viele Unternehmen haben ihre Integrationslogik, Authentifizierung und Betriebsstandards bereits in .NET. Wenn Agenten diese Welt nutzen sollen, braucht es genau solche SDKs: nicht nur Protokolladapter, sondern Plattformintegration.
Der beste Einstieg ist aus meiner Sicht: erst QuickstartWeatherServer und QuickstartClient, dann AspNetCoreMcpServer, danach je nach Ziel ProtectedMcpServer, WeatherAppServer oder TasksExtension. Dann sieht man schnell, dass MCP in C# nicht nur ein Tool-Call-Mechanismus ist, sondern eine Architekturfrage: Welche Fähigkeiten stelle ich Agenten bereit, in welchem Transport, mit welcher Identität und mit welcher Verantwortung?