KI-Agenten sind nur so nützlich wie die Systeme, auf die sie zugreifen können. Wer eigene MCP-Server mit .NET entwickelt, macht genau die Anwendungen für Agenten nutzbar, die im Unternehmen wirklich zählen: das CMS, die Zeiterfassung, das ERP. Statt auf fertige Integrationen zu warten, definieren Sie selbst, welche Aktionen ein Agent ausführen darf – und welche nicht. Bei Lauth IT setzen wir diesen Ansatz seit einiger Zeit produktiv ein und teilen in diesem Praxisleitfaden unsere Erfahrungen.

Was ist ein MCP-Server – kurz erklärt

Das Model Context Protocol (MCP) ist ein offener Standard, der beschreibt, wie KI-Anwendungen mit externen Systemen sprechen. Ein MCP-Server ist ein kleines Programm, das einem Agenten sogenannte Tools anbietet – klar definierte Funktionen wie „Inhalt abfragen" oder „Eintrag anlegen". Der Agent sieht die Tool-Beschreibungen, entscheidet situativ, welches Tool er aufruft, und der Server übersetzt den Aufruf in echte API-Requests gegen Ihr System.

Man kann den MCP-Server damit auch als Doorkeeper zur eigentlichen API verstehen: Der Agent bekommt nie die volle Schnittstelle zu sehen, sondern nur die bewusst ausgewählten Endpunkte, die Sie ihm als Tools bereitstellen. Was der Server nicht anbietet, existiert für den Agenten schlicht nicht – Löschfunktionen, Administrations-Endpunkte oder sensible Datenbereiche bleiben so von vornherein außerhalb seiner Reichweite.

Für .NET-Teams ist der Einstieg erfreulich einfach: Das offizielle MCP C#-SDK (NuGet-Paket ModelContextProtocol, gepflegt in Zusammenarbeit mit Microsoft) nimmt einem das Protokoll-Handling komplett ab. Man dekoriert C#-Methoden als Tools, das SDK kümmert sich um den Rest. Grundlagen zum Thema haben wir bereits in unserem Artikel MCP im Praxiseinsatz beleuchtet.

Praxisbeispiel: Unsere MCP-Server für Squidex und Kimai

Bei Lauth IT laufen mehrere selbst entwickelte MCP-Server in C# produktiv im Arbeitsalltag:

Beide Server sind bewusst schlank gebaut: Sie laufen als stdio-MCP-Server, werden also lokal gestartet (etwa per dotnet run) und direkt von der Copilot- bzw. Agenten-Umgebung angesprochen. Die Konfiguration – API-URL und Client-Credentials – erfolgt über Umgebungsvariablen. Kein zusätzlicher Webserver, kein offener Port, keine neue Angriffsfläche.

Lessons Learned aus dem Produktivbetrieb

1. Tools klein und klar schneiden

Ein Mega-Tool, das „alles mit Inhalten" kann, überfordert Agenten. Bewährt hat sich ein feiner Schnitt: query, get, create, patch, change_status – jedes Tool macht genau eine Sache und beschreibt sie präzise. Das verbessert die Trefferquote des Agenten deutlich und vereinfacht die Rechtevergabe.

2. Draft-first: Der Mensch bleibt in der Verantwortung

Schreibende Tools erzeugen bei uns grundsätzlich Entwürfe, keine Veröffentlichungen. Der Agent darf Vorarbeit leisten – überarbeitet, finalisiert und freigegeben wird von Menschen. Dieses Prinzip kostet wenig und verhindert die unangenehmsten Fehlerklassen.

Sicherheitsfachlich ist das übrigens nichts Neues: Es ist Separation of Duties (SoD) – eines der Kernprinzipien der Informationssicherheit, übertragen auf KI-Agenten. Die Instanz, die Inhalte erstellt, ist nie dieselbe, die sie freigibt. Und falls doch einmal etwas schiefgeht, zahlt sich ein CMS mit Versionierung aus: Squidex hält für jeden Inhalt Revisionen vor, sodass sich Bearbeitungsstände per Rollback zurücksetzen lassen – ein eingebautes Mini-Backup als doppelte Sicherheit. Warum kontrollierte Umgebungen für Agenten generell entscheidend sind, zeigt unser Beitrag zu echten Sandboxes für KI-Agenten.

3. Lese-Tools müssen Drafts sehen können

Eine Feinheit, die uns Debugging-Zeit gekostet hat: Wenn Lese-Tools nur veröffentlichte Inhalte liefern, wirken frisch angelegte Drafts für den Agenten wie gelöscht – er legt sie im Zweifel doppelt an. In Squidex löst das der X-Unpublished-Header. Solche API-Details der Zielsysteme sollte man früh klären, sie entscheiden über einen konsistenten Agenten-Workflow.

4. Client-Credentials mit minimalen Rechten

Der MCP-Server bekommt eigene Zugangsdaten mit genau den Rechten, die seine Tools brauchen – niemals einen Admin-Zugang, das klassische Least-Privilege-Prinzip. Fällt der Agent aus der Rolle oder wird ein Credential kompromittiert, bleibt der Schaden begrenzt.

5. Das offizielle C#-SDK nutzen

Das ModelContextProtocol-NuGet-Paket macht den Einstieg leicht: Protokoll, Transport und Tool-Registrierung sind gelöst, Sie konzentrieren sich auf Ihre Fachlogik. Ein eigener stdio-Server für ein internes System ist damit eher eine Frage von Tagen als von Wochen.

Fazit: Klein anfangen, Kontrolle behalten

Eigene MCP-Server sind der pragmatischste Weg, interne Systeme für KI-Agenten zu öffnen – mit .NET und dem offiziellen SDK auch ohne großes Vorprojekt. Wichtig ist weniger die Technik als der Zuschnitt: kleine Tools, Separation of Duties, minimale Rechte – die klassischen Security-Prinzipien verlieren durch KI nicht an Gültigkeit, sie werden wichtiger. Ob ein Agent mit MCP-Anbindung oder ein anderer Ansatz besser passt, hängt vom Anwendungsfall ab – eine Einordnung liefert unser Vergleich KI-Agenten vs. Skills.

Sie möchten Ihre eigenen Systeme für KI-Agenten nutzbar machen? Auf unserer Seite zu MCP-Integrationen für Unternehmen zeigen wir, wie wir Sie dabei unterstützen.