MCP-Referenzserver: was sie zeigen und was sie auslassen

modelcontextprotocol/servers ist die Referenzsammlung für das Model Context Protocol: sieben kleine Server, die von der MCP-Steuerungsgruppe gepflegt werden und von denen jeder einen Teil des Protokolls demonstriert, nicht etwa einen Job gut erledigt. Als Produkt gelesen ist es Lehrmaterial mit einem ungewöhnlich ehrlichen README, und die hier vertretene Position lautet: lesen und lokal ausführen, aber niemals ausrollen — das Repositorium sagt wortwörtlich, dass die Server keine Produktionslösung sind, und die Sicherheitsrichtlinie lehnt Schwachstellmeldungen dagegen ab. Gut ist die Sammlung darin, im lauffähigen Code zu zeigen, was ein Server implementieren muss, geschrieben von den Verfassern der Spezifikation.

Sie steht zwischen der Spezifikation auf modelcontextprotocol.io und den zehn offiziellen SDKs und konkurriert nicht mit der MCP Registry, in der veröffentlichte Server zum praktischen Gebrauch gelistet sind. Nichts hier ersetzt einen Suchindex, ein Browser-Werkzeug oder eine Ticket-Integration. Die Sammlung löste ein früheres Sammelsurium einzelner Beispiele ab, von denen die meisten in einem separaten Archivrepositorium liegen und weiterhin in alten Anleitungen auftauchen.

Was es ist

Ein npm-Workspace mit sieben Paketen unter src/, veröffentlicht auf npm als @modelcontextprotocol/server-* und auf PyPI als mcp-server-*. Vier Server sind TypeScript, drei sind Python, und jeder isoliert ein anderes Protokollmerkmal: Zugriffskontrolle, Prompts und Ressourcen, ein Wissensgraph, ein Werkzeug, das seine eigene Ausgabe umschreibt, Web-Abruf, Repository-Operationen, Zeitzonen.

• Rund 91.100 Stars und 11.800 Forks Anfang Oktober 2026, mit 4.194 Commits auf main.
• Sieben Referenzserver in src/: everything, fetch, filesystem, git, memory, sequentialthinking und time.
• Dreizehn eingestellte Server, darunter GitHub, Slack, PostgreSQL, SQLite, Puppeteer und Brave Search, zogen nach servers-archived; den Brave-Server betreut nun Brave selbst.
• Das README verweist jetzt jeden, der einen sucht, an die MCP Registry und behält das Repositorium nur für die Referenzimplementierungen.
• Lizenz: Apache-2.0 für neue Beiträge, älterer Code weiterhin unter MIT, wie die LICENSE-Datei erklärt.
• Serverpakete verwenden Kalenderversionen: 2026.8.31 für die TypeScript-Pakete, 2026.8.18 für die Python-Pakete.
• Veröffentlicht wird aus einer geschützten CI-Workflow per OIDC Trusted Publishing mit Provenance-Attestaten; im Release-Pfad gibt es keine Registry-Tokens.

Das Repositorium, Server für Server

Das Layout ist bewusst flach: ein Verzeichnis pro Server unter src/, ein package.json im Hauptverzeichnis, das sie als npm-Workspaces verdrahtet, und einige Betriebsdokumente auf oberster Ebene. Ein Server-Verzeichnis von oben nach unten zu lesen ist der schnellste Weg, das Protokoll zu lernen, weil jedes einzelne in einer Sitzung durchzubekommen ist.

Neben src/ liegen im Hauptverzeichnis ADDITIONAL.md für Frameworks und Clients aus der Community, RELEASING.md für den Weg der Pakete in die Registries, SECURITY.md, CLAUDE.md, eine .mcp.json für die eigene Tooling-Kennung und ein scripts-Verzeichnis. Der everything-Server bildet die Ausnahme von der Flachheit: Er trägt ein docs-Verzeichnis mit Architektur-, Feature- und Erweiterungspunkten und verhält sich mehr wie eine Konformitäts-Prüfvorrichtung denn wie eine Vorlage.

SDKs und Sprachversionen

Das README listet zehn offizielle SDKs auf — C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Swift und TypeScript — und stellt klar, dass die Referenzserver darauf aufbauen. In der Praxis sind die TypeScript-Pakete aktuell, während die Python-Pakete eine Hauptversion zurückliegen; das README des time-Servers sagt das in einem Satz.

Der time-Servers begründet die Lücke ungeschminkt: SDK 2.0 hat die von ihm genutzten APIs umbenannt, und der Port läuft. Das ist der ehrliche Preis einer Referenzsammlung — die Beispiele folgen der Spezifikation eng, die Python-Hälfte folgt den SDK-Hauptversionen weniger eng. Wer heute einen Python-Server kopiert, liest lauffähigen Code gegen die 1.x-API: gut zum Studium, eine Falle für neue Arbeit.

Wie ein Server tatsächlich läuft

Ein Client, der mit einem Stdio-Server konfiguriert ist, startet ihn als Kindprozess und spricht newline-delimitiertes JSON-RPC über stdin und stdout. Es lauscht kein Port. Beim initialize-Handshake erklären beide Seiten ihre Fähigkeiten: Der Server meldet, welche Tools, Ressourcen und Prompts er implementiert, der Client meldet, ob er Roots, Sampling und Elicitation annimmt — und alles danach ist Anfrage, Antwort oder Benachrichtigung.

Die drei Primitive sind nicht austauschbar. Ein Tool ist etwas, das Modell aufruft; eine Ressource liegt an einer URI für die Anwendung oder den Nutzer; ein Prompt ist eine Vorlage, die der Nutzer wählt. Der everything-Server implementiert alle drei dazu Sampling, Elicitation, Fortschrittsbenachrichtigungen, strukturierte Tool-Ausgabe und die neuere Task-Erweiterung — deshalb ist es das eine Verzeichnis, das sich zu lesen lohnt, wenn ein Protokollmerkmal unklar ist.

Erste Schritte

Nichts muss kompiliert werden. Ein Server ist ein Paket auf npm oder PyPI, und die Konfiguration unten ist die gesamte Installation: Der Client führt den Befehl aus, der Befehl antwortet über stdout, und das Modell erhält eine Tool-Liste.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    },
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "/path/to/repo"]
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Einen selbst zu schreiben, ist kaum schwerer. Das TypeScript-SDK stellt ein Serverobjekt mit registerTool, registerResource und registerPrompt bereit, dazu einen Transport. Der Snippet unten ist ein vollständiger Server mit einem einzigen Tool und hat dieselbe Form wie die Beispiele filesystem und memory.

import { readFile } from "node:fs/promises";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "wordcount", version: "0.1.0" });

server.registerTool(
  "count_words",
  {
    title: "Count words",
    description: "Count the words in a UTF-8 text file",
    inputSchema: { path: z.string() },
  },
  async ({ path }) => {
    const words = (await readFile(path, "utf8")).split(/\s+/).filter(Boolean).length;
    return { content: [{ type: "text", text: String(words) }] };
  },
);

await server.connect(new StdioServerTransport());

Sicherheitslage

Die Sammlung sagt ungewöhnlich klar, was sie nicht ist. Der Warnblock des README besagt, dass die Server Features und SDK-Nutzung demonstrieren, dass Entwickler ihre eigenen Sicherheitsanforderungen prüfen müssen und dass die Server nicht produktionsreif sind. SECURITY.md stellt dann fest, dass gegen dieses Repositorium gar keine Schwachstellmeldungen angenommen werden — das deutlichste Signal für den Status: Die SDKs werden unterstützt, die Beispiele nicht.

• Jeder Server ist ein lokaler Kindprozess mit den Rechten des Nutzers, der ihn gestartet hat; Tool-Aufrufe des Modells werden dadurch zu Datei-, Netzwerk- und Repository-Operationen in diesem Konto.
• Der Filesystem-Server ist der einzige mit Zugriffskontrolle: eine Verzeichnis-Whitelist aus Kommandozeilenargumenten oder zur Laufzeit ersetzt vom Client über Roots — und ein Pfad-Check ist kein Prozess-Sandbox.
• Der Fetch-Server setzt Seiten in Markdown um, respektiert robots.txt und bietet einen konfigurierbaren User-Agent und Proxy, soweit die Sammlung überhaupt auf ausgehende Netzwerk-Hygiene achtet.
• Memory speichert einen Wissensgraph in einer lokalen JSON-Datei ohne Authentifizierung, und git schreibt in das übergebene Repository-Pfadverzeichnis; keiner davon ist für ein Netzwerk gedacht.
• Releases laufen als manueller Workflow-Dispatch in eine geschützte GitHub-Umgebung mit erforderlichem Reviewer, veröffentlicht nach npm und PyPI mit Provenance-Attestaten und ohne Registry-Tokens.

Wo es hakt

Sieben Server sind eine kleine Stichprobe, und keiner davon ist ein Dienst. Ein Authentifizierungsmodell zum Kopieren gibt es nicht, weil Stdio per Konstruktion lokal ist und die HTTP-Routen im everything-Server Entwicklungstransporte sind; ebenso wenig gibt es Rate-Limiting, eine Support-Aussage oder eine Deployment-Geschichte jenseits eines docker run im README. Die archivierten Server sind weiterhin aus Jahren von Tutorials verlinkt, wer einer alten Anleitung folgt, landet also in einem bewusst umgezogenen Repositorium. Und die Python-Hälfte der Sammlung hinkt dem SDK hinterher, das sie zeigen soll.

Der ehrliche Vergleich fragt nicht, welche dieser vier gewinnt, sondern was jede lehrt. Ein Framework bringt einen Server schneller ans Laufen und versteckt die Teile, die zwischen Spezifikationsversionen wechseln. Die Registry liefert Code, den jemand anderer geschrieben hat, mit der Prüfung, die dieser Autor vorgenommen hat. Die Referenzserver sind die einzige Option, deren Quellcode von den Verfassern der Spezifikation stammt — und genau deshalb lohnt sich das Lesen, nicht das Ausliefern.

Fazit

Nutze es als Dokumentation, die ausführt. Empfohlen für alle, die einen MCP-Server bauen, für alle, die einen prüfen, und für alle sehen wollen, wie Tools, Ressourcen und Sampling auf dem Draht aussehen; nicht empfohlen als Basis-Repositorium, als Quelle produktiver Tools oder als Liste von Servern für den eigenen Client.

1. Lies src/, bevor du einen Server schreibst: filesystem für Zugriffskontrolle, everything für die volle Protokollfläche, memory für ein nicht triviales Tool-Design.
2. Führe die Referenzserver lokal aus, um das Protokoll zu lernen oder einen Client zu testen, und behandle ihre Tool-Listen als Testfixtures, nicht als Produkt.
3. Pinne Paketversionen in jeder Konfiguration, die du behältst, statt des -y-Flags aus den README-Beispielen.
4. Keinen Referenzserver auf ein geteiltes Konto ausrollen: keine Authentifizierung, keine Rate-Limits, keine Schwachstellannahme.
5. Protokoll-Funde an die SDK-Repositorien senden, und wenn es um einen ausführbaren Server geht, die Registry statt dieses Repositoriums verwenden.

The servers in this repository are intended as reference implementations to demonstrate MCP features and SDK usage. They are meant to serve as educational examples for developers building their own MCP servers, not as production-ready solutions.

Quellen

1. MCP-Referenzserver-Repositorium
2. README und Serverliste des Repositoriums
3. Sicherheitsrichtlinie
4. Release-Prozess und Trusted Publishing
5. README des Filesystem-Servers
6. Feature-Liste des Everything-Servers
7. MCP Registry
8. Archivierte Referenzserver
9. Dokumentation des Model Context Protocol
10. TypeScript-MCP-SDK
11. Python-MCP-SDK
12. FastMCP auf PyPI