Acht Sprachen, acht SDKs auf sehr unterschiedlichem Reifegrad und je ein funktionierendes Beispiel. Wähl deine.
Die Sprache ist die leichte Entscheidung. Jemanden dazu zu bringen, deinen Server auszuprobieren, ist die schwere — MCP Showcase macht aus jedem MCP-Endpunkt ein Live-Playground mit Doku für jedes Tool.
Inklusive der Frage, ob es ein offiziell gepflegtes SDK gibt — was stärker schwankt, als man erwartet.
Jede Seite zeigt eine vollständige Tool-Definition in dieser Sprache, keinen Pseudocode.
Der MCP Inspector bestätigt den Handshake und zeigt genau das, was ein Agent zu sehen bekommt.
Das Protokoll ist überall identisch — Tools, Resources und Prompts verhalten sich gleich, unabhängig davon, worin du sie schreibst. Unterschiedlich ist, wie viel dir das SDK abnimmt, wie Schemas deklariert werden und ob die Bibliothek überhaupt offiziell gepflegt wird.
| Sprache | SDK | Status | Installation |
|---|---|---|---|
| Python | modelcontextprotocol/python-sdk (FastMCP) | Offiziell | pip install mcp |
| TypeScript | modelcontextprotocol/typescript-sdk | Offiziell | npm install @modelcontextprotocol/sdk zod |
| Go | modelcontextprotocol/go-sdk | Offiziell | go get github.com/modelcontextprotocol/go-sdk |
| Java | modelcontextprotocol/java-sdk | Offiziell | Maven: io.modelcontextprotocol.sdk:mcp |
| C# | modelcontextprotocol/csharp-sdk | Offiziell | dotnet add package ModelContextProtocol |
| Rust | modelcontextprotocol/rust-sdk (rmcp) | Offiziell | cargo add rmcp |
| Ruby | community SDKs | Community | gem install mcp |
| PHP | community SDKs | Community | composer require ... |
Die, in der deine API ohnehin geschrieben ist. Ein MCP-Server ist eine dünne Hülle um Code, den du hast, und ihn auf mehrere Laufzeitumgebungen zu verteilen bringt dir nichts außer einem weiteren Deployment, das gepflegt werden will. Wenn du wirklich bei null anfängst: Python und TypeScript haben die reifsten SDKs und mit Abstand die meisten Beispiele zum Abschauen.
Der eine Fall, in dem die Sprachwahl für sich genommen zählt: Ruby und PHP haben kein SDK unter
modelcontextprotocol, du verlässt dich also auf Community-Portierungen, deren
Aktualität du prüfen solltest, bevor du darauf aufbaust.
Tool-Beschreibungen entscheiden, ob sich der Agent vernünftig verhält, und kein SDK schreibt sie für dich. Sie werden vom Modell gelesen und nicht von deinem Team, und sie gehen bei jeder Anfrage erneut mit — sie sind also gleichzeitig das Genauigkeits- und das Kostenproblem. Genau deshalb endet jede Seite hier an derselben Stelle.
Alles hier ist für die Person, die den Server baut. MCP Showcase ist für alle anderen: Richte es auf einen beliebigen MCP-Endpunkt, und es entsteht ein Live-Playground mit Doku für jedes Tool — damit die Bewertung deines Servers einen Klick kostet statt eines Checkouts und eines Builds.