Ein MCP-Server (Model Context Protocol) ist die Brücke, über die ein Sprachmodell einen externen Dienst tatsächlich bedienen kann, nicht nur darüber spricht. Das Schnittstellen-Gerüst führt durch die vier Phasen dieses Baus: Recherche der Protokoll-Spezifikation und der passenden SDK-Dokumentation, Implementierung von Kerninfrastruktur und einzelnen Tools mit typisierten Ein- und Ausgaben, Review und Test über den MCP Inspector, und die Erstellung von zehn realistischen Evaluationsfragen, die zeigen, ob ein Modell den Server produktiv nutzt.
\nGedacht ist der Skill für Entwicklerinnen und Entwickler, die eine externe API oder einen internen Dienst so anbinden wollen, dass ein Sprachmodell darauf verlässlich zugreifen kann, sei es in TypeScript oder in Python. Besonders hilfreich, wenn bereits eine API existiert und die eigentliche Frage nicht das Ob, sondern das Wie der Anbindung ist: Tool-Zuschnitt, Namenskonventionen, Fehlerbehandlung, Paginierung.
\nDie ehrliche Grenze: Dieser Skill setzt eine Umgebung mit Terminal-, Datei- und Webzugriff voraus, etwa Claude Code, da er tatsächlich Code schreibt, baut und testet. Er ersetzt kein Studium der MCP-Spezifikation selbst und keine Kenntnis der Ziel-API, er strukturiert nur den Weg dorthin. Die im Original mitgelieferten Vertiefungsdateien zu TypeScript, Python und Evaluationen braucht die Umgebung zusätzlich zu dieser Anleitung.
\n" }, { "id": "skill-text", "title": "Skill-Text", "html": "Dies ist ein offen attribuierter externer Skill von Anthropic. Quelle: https://github.com/anthropics/skills
\nDieser Skill setzt eine Umgebung mit Terminal-, Datei- und Webzugriff voraus, etwa Claude Code, da er einen vollständigen MCP-Server recherchiert, implementiert und testet. Kopieren Sie die Anleitung unten in Ihre eigene Skill-Umgebung, wenn Sie diesen Skill selbst einrichten möchten. Sie beschreibt Vorgehen, Architekturentscheidungen und Qualitätskriterien; die referenzierten Vertiefungsdateien des Originals (sprachspezifische Implementierungsguides, Best-Practice-Referenz, Evaluationsguide) braucht die Umgebung zusätzlich. Als Datei: mcp-builder.de.json
\n" } ], "schritte": [ { "nr": 1, "titel": "Ziel und Sprache festlegen", "beschreibung": "Ziel-API oder Ziel-Dienst, die gewünschte Programmiersprache und die verfügbare API-Dokumentation werden benannt.", "rolle": "mensch" }, { "nr": 2, "titel": "Recherche und Planung", "beschreibung": "MCP-Spezifikation und SDK-Dokumentation werden studiert, Tool-Zuschnitt, Namenskonventionen sowie Input- und Output-Schemata werden festgelegt.", "rolle": "automatisch" }, { "nr": 3, "titel": "Implementierung", "beschreibung": "Kerninfrastruktur wie API-Client, Fehlerbehandlung und Paginierung sowie die einzelnen Tools werden gebaut.", "rolle": "automatisch" }, { "nr": 4, "titel": "Test und Review", "beschreibung": "Build beziehungsweise Syntax werden geprüft, der Server wird über den MCP Inspector getestet.", "rolle": "automatisch" }, { "nr": 5, "titel": "Evaluationsfragen erstellen", "beschreibung": "Zehn realistische Fragen werden formuliert, selbst gelöst, verifiziert und als XML-Datei dokumentiert.", "rolle": "automatisch" }, { "nr": 6, "titel": "Server abnehmen", "beschreibung": "Der fertige Server wird vor dem produktiven Einsatz durchgesehen und freigegeben.", "rolle": "freigabe" } ], "herausgeber": "Voyage Digital", "version": "2.0", "stand": "2026-07-26", "umsetzung": [ { "titel": "Zieldienst auswählen", "text": "Der Einstieg gelingt am besten mit einem Dienst, der bereits eine dokumentierte API hat und im Team kurzfristig gebraucht wird." }, { "titel": "Sprache und Transport festlegen", "text": "TypeScript mit Streamable HTTP ist der empfohlene Standardweg für Remote-Server, stdio bleibt lokalen Servern vorbehalten." }, { "titel": "Skill in einer agentischen Umgebung einsetzen", "text": "Der Skill-Text wird in eine Umgebung mit Terminal-, Datei- und Webzugriff geladen, etwa Claude Code." }, { "titel": "Server testen und abnehmen lassen", "text": "Vor dem produktiven Einsatz wird der Server über den MCP Inspector geprüft und von einer zweiten Person durchgesehen." }, { "titel": "Muster für weitere Dienste wiederverwenden", "text": "Bewährte Namenskonventionen und Fehlerbehandlung werden beim nächsten MCP-Server erneut eingesetzt." } ], "zutaten": [ "Ziel-API", "Programmiersprache", "API-Dokumentation" ], "beispielSzenario": "Ein Entwicklerteam möchte sein internes Ticketsystem für ein Sprachmodell zugänglich machen, damit es offene Tickets lesen, kommentieren und weiterleiten kann. Ausgehend von der vorhandenen REST-API entsteht mit dem Schnittstellen-Gerüst ein TypeScript-basierter MCP-Server: sprechende Tool-Namen wie tickets_list und tickets_add_comment, typisierte Ein- und Ausgaben, eine Fehlerbehandlung mit konkreten Hinweisen und zehn Testfragen, die zeigen, dass ein Modell offene Tickets zuverlässig findet und bearbeitet.", "eingaben": [ { "feld": "Ziel-API oder Ziel-Dienst, den der MCP-Server anbinden soll", "pflicht": true }, { "feld": "Programmiersprache: TypeScript oder Python (TypeScript empfohlen)", "pflicht": true }, { "feld": "API-Dokumentation oder Zugriff darauf", "pflicht": true }, { "feld": "Transportart: Streamable HTTP für Remote-Server, stdio für lokale Server", "pflicht": false }, { "feld": "Bestehender Server-Code, falls eine vorhandene Implementierung erweitert wird", "pflicht": false } ], "ausgabe": "Ein recherchiertes Implementierungskonzept, der vollständige Server-Code mit typisierten Tools, Fehlerbehandlung und Paginierung, eine Testroutine über den MCP Inspector und zehn Evaluationsfragen zur Prüfung, ob ein Sprachmodell den Server produktiv nutzen kann.", "prompt": "# ROLLE\nSie erstellen MCP-Server (Model Context Protocol), die es Sprachmodellen ermöglichen, über gut gestaltete Tools mit externen Diensten zu interagieren. Die Qualität eines MCP-Servers bemisst sich daran, wie zuverlässig er einem Modell hilft, reale Aufgaben zu lösen.\n\n# PHASE 1: RECHERCHE UND PLANUNG\n\n## Modernes MCP-Design verstehen\nWägen Sie umfassende API-Abdeckung gegen spezialisierte Workflow-Tools ab. Workflow-Tools sind bei einzelnen Aufgaben komfortabler, umfassende Abdeckung gibt Agenten mehr Freiheit, Operationen selbst zu kombinieren. Im Zweifel priorisieren Sie umfassende API-Abdeckung.\n\nVergeben Sie klare, sprechende Tool-Namen mit konsistenten Präfixen (zum Beispiel github_create_issue, github_list_repos) und handlungsorientierter Benennung.\n\nHalten Sie Tool-Beschreibungen knapp und ermöglichen Sie Filter und Paginierung, damit Agenten fokussierte, relevante Daten erhalten.\n\nFormulieren Sie Fehlermeldungen so, dass sie den Agenten mit konkreten Vorschlägen zu einer Lösung führen.\n\n## MCP-Spezifikation und Framework-Dokumentation studieren\nNutzen Sie die Sitemap unter https://modelcontextprotocol.io/sitemap.xml, um relevante Seiten zu finden, und rufen Sie einzelne Seiten mit der Endung .md im Markdown-Format ab. Prüfen Sie insbesondere die Architekturübersicht, die Transportmechanismen (Streamable HTTP, stdio) sowie Tool-, Resource- und Prompt-Definitionen.\n\nEmpfohlener Stack: TypeScript für Server (gute SDK-Unterstützung, breite Kompatibilität, Modelle generieren zuverlässigen TypeScript-Code), Streamable HTTP mit zustandslosem JSON für Remote-Server, stdio für lokale Server.\n\nLaden Sie die SDK-Dokumentation der gewählten Sprache (TypeScript oder Python) sowie die zugehörigen sprachspezifischen Implementierungsguides, bevor Sie zu implementieren beginnen.\n\n## Implementierung planen\nVerstehen Sie die Ziel-API: zentrale Endpunkte, Authentifizierung, Datenmodelle. Priorisieren Sie umfassende API-Abdeckung und listen Sie zunächst die häufigsten Operationen.\n\n# PHASE 2: IMPLEMENTIERUNG\n\n## Projektstruktur aufsetzen\nRichten Sie die Projektstruktur nach dem sprachspezifischen Guide ein (Package- beziehungsweise Modulstruktur, Abhängigkeiten, Konfigurationsdateien).\n\n## Kerninfrastruktur\nErstellen Sie gemeinsame Bausteine: einen API-Client mit Authentifizierung, Fehlerbehandlung, Antwortformatierung (JSON oder Markdown) und Paginierungsunterstützung.\n\n## Tools implementieren\nFür jedes Tool gilt:\n- Input-Schema mit Zod (TypeScript) oder Pydantic (Python), mit Einschränkungen, klaren Beschreibungen und Beispielen.\n- Output-Schema, wo möglich, für strukturierte Daten.\n- Eine knappe Funktionsbeschreibung mit Parametern und Rückgabetyp.\n- Asynchrone Verarbeitung für I/O-Operationen, saubere Fehlerbehandlung mit konkreten Hinweisen, Paginierung wo anwendbar.\n- Annotationen: readOnlyHint, destructiveHint, idempotentHint, openWorldHint.\n\n# PHASE 3: REVIEW UND TEST\nPrüfen Sie den Code auf Duplikate, konsistente Fehlerbehandlung, vollständige Typisierung und klare Tool-Beschreibungen.\n\nTypeScript: Build mit npm run build verifizieren, mit dem MCP Inspector testen (npx @modelcontextprotocol/inspector).\nPython: Syntax mit python -m py_compile prüfen, ebenfalls mit dem MCP Inspector testen.\n\n# PHASE 4: EVALUATIONEN ERSTELLEN\nErstellen Sie zehn Evaluationsfragen, um zu prüfen, ob ein Sprachmodell den Server produktiv nutzen kann.\n\nVorgehen: Tools sichten, mit Nur-Lese-Operationen die verfügbaren Daten explorieren, zehn komplexe, realistische Fragen formulieren, jede Frage selbst lösen und die Antwort verifizieren.\n\nJede Frage muss unabhängig von anderen Fragen beantwortbar sein, ausschließlich Nur-Lese-Operationen benötigen, mehrere Tool-Aufrufe und echte Exploration erfordern, auf einem realen Anwendungsfall beruhen, eine einzige, per Textvergleich verifizierbare Antwort haben, und zeitstabil sein.\n\nFormat als XML-Datei:\n```xml\n