Kostenloses Tool

REST-API zu MCP-Server in C#

Was wirklich dazugehört, eine REST-API als MCP-Server in C# bereitzustellen — das SDK, ein funktionierendes Tool und der Teil, der entscheidet, ob ein Agent es richtig nutzt.

Offizielles SDK modelcontextprotocol/csharp-sdk
Installation
dotnet add package ModelContextProtocol
Ein funktionierendes MCP-Tool in C# 
[McpServerToolType]
public static class OrderTools
{
    [McpServerTool, Description("Look up one order by its id and return its current status.")]
    public static async Task<string> GetOrder(
        IOrderService orders,
        [Description("The order id to look up")] string orderId)
        => await orders.FetchAsync(orderId);
}
Teste, was du gebaut hast Tools aus einer OpenAPI-Spec generieren

Er läuft. Nur sehen kann das sonst niemand.

Ein funktionierender Server ist der Punkt, an dem die Arbeit endet und das Verkaufen beginnt. Richte MCP Showcase darauf und erhalte ein Live-Playground, das deine Kunden ausprobieren können — mit generierter Doku für jedes Tool.

Kostenlos starten MCP-Server-Verzeichnis erkunden

So funktioniert es

link
SDK installieren

Steht oben, zusammen mit der Info, ob es offiziell gepflegt wird oder ein Community-Projekt ist — was in manchen Sprachen mehr zählt als in anderen.

play_circle
Einen Endpunkt kapseln

Fang mit einem einzigen Tool an, nicht mit deiner ganzen API. Tool-Definitionen gehen bei jeder Anfrage ans Modell, und die Treffsicherheit bei der Auswahl sinkt, je länger die Liste wird.

checklist
Testen, bevor du einen Agenten anschließt

Lass die deployte URL durch den MCP Inspector laufen, um zu bestätigen, dass der Handshake klappt und die Tools so erscheinen, wie du es wolltest.

Das SDK für C#

dotnet add package ModelContextProtocol — modelcontextprotocol/csharp-sdk, offiziell gepflegt.

Attribute plus Dependency Injection

Tools werden mit Attributen markiert und über den Standard-DI-Container von .NET aufgelöst, ein Tool kann also neben den vom Modell gelieferten Argumenten auch injizierte Services als Parameter nehmen. Das ist bequem und zugleich der einfachste Weg, versehentlich einen internen Service über eine Tool-Signatur nach außen zu geben — prüfe, was von jedem Tool aus tatsächlich erreichbar ist.

Einen REST-Endpunkt kapseln

Ein MCP-Server ist eine dünne Schicht über Code, den du schon hast. Jedes Tool braucht drei Dinge: einen Namen, eine Beschreibung, die sagt, was es tut und wann man es wählt, und ein Input-Schema. Das SDK für C# kümmert sich um das Protokoll; was du schreibst, ist die Abbildung dieser Argumente auf deinen bestehenden HTTP-Aufruf.

Fang mit einem Endpunkt an statt mit deiner ganzen API. Tool-Definitionen werden bei jeder einzelnen Anfrage erneut ans Modell geschickt, jede ist also dauerhafte Kontextkosten — und die Fähigkeit des Modells, richtig zu wählen, sinkt mit wachsender Liste. Acht gut beschriebene Tools schlagen achtzig.

Der Teil, bei dem es nicht um C# geht

Egal welche Sprache du nutzt: Die Beschreibungen entscheiden, ob sich der Agent vernünftig verhält. Sie werden vom Modell gelesen, nicht von deinen Kollegen, und ein Tool, das in drei Worten beschrieben ist, wird auf Verdacht aufgerufen. Prüfen kannst du deine mit dem MCP-Schema-Linter, und was die Liste pro Anfrage kostet, zeigt dir der Token-Rechner.

Verwandte Tools und Anleitungen

Ein funktionierender Server ist die halbe Miete

Wenn er läuft, bleibt das Problem, dass niemand erkennen kann, was er tut. Ein Interessent kann deinen C#-Quellcode nicht lesen und wird keinen Client installieren, um es herauszufinden. MCP Showcase richtet sich auf dieselbe URL und erzeugt ein Live-Playground mit generierter Doku für jedes Tool — damit die Bewertung deines Servers einen Klick kostet.

Häufig gestellte Fragen

Kapsle jeden Endpunkt, den ein Agent erreichen soll, in ein Tool: ein Name, ein Satz dazu, was es tut und wann man es nutzt, und ein Input-Schema. Das SDK für C# kümmert sich um das Protokoll; was du schreibst, ist die Abbildung von Tool-Argumenten auf deinen bestehenden HTTP-Aufruf.

Nein, und das ist der häufigste Fehler. Tool-Definitionen werden bei jeder einzelnen Anfrage erneut gesendet — achtzig Endpunkte sind also achtzig Beschreibungen im Kontextfenster jeder Runde, und die Fähigkeit des Modells, das richtige zu wählen, fällt mit wachsender Liste deutlich ab. Fang mit den wenigen an, die ein Agent wirklich braucht.

Das Badge über dem Code sagt es dir. Wo es kein offizielles SDK gibt, unterscheiden sich Community-Lösungen darin, wie eng sie der Spezifikation folgen — prüfe, wann die Bibliothek zuletzt einer Protokollrevision gefolgt ist, gerade bei Transporten, bevor du darauf aufbaust.

Streamable HTTP für alles, was deployt ist. Clients versuchen es zunehmend zuerst, und manche fallen nicht mehr auf das ältere HTTP+SSE zurück — was sich nicht als Fehler zeigt, sondern als Client, der deinen Server schlicht nicht sieht.

Beim Lesen des eigenen Codes merkst du es nicht, weil du längst weißt, was die Tools tun. Lass den Server durch den Schema-Linter laufen: Er prüft Beschreibungen und Input-Schemas so, wie ein Modell sie liest, und markiert die, bei denen ein Agent raten müsste.

Weitere kostenlose MCP-Tools

MCP Inspector Online

MCP-Server-URL einfügen und alle Tools, Resources und Prompts sehen, mit vollständigen Schemas und rohem Request-Log. Nichts zu installieren.
MCP Server Tester

Prüfen Sie, ob Ihr MCP-Server wirklich funktioniert. URL einfügen und einen Pass/Fail-Bericht zu Verbindung, Handshake, Transport und bereitgestellten Tools erhalten.
MCP Security Scanner

Bevor Sie einen Agenten auf einen MCP-Server richten, sehen Sie, worum er bittet. Bewertet von A bis F zu Transport, Authentifizierung, Tool-Poisoning-Merkmalen und gefährlichen Parametern.
MCP Token Calculator

Tool-Definitionen werden bei jeder Anfrage gesendet, nicht einmalig. Füge deine MCP-Server-URL ein und sieh, wie viele Tokens das sind, welche Tools am schwersten sind und was es kostet.
Alle kostenlosen Tools