Referenzen und Werkzeuge
Alle Adressen wurden am 31.08.2026 geprüft.
Die Spezifikation
Das Model Context Protocol wird offen entwickelt. Wer eine Frage hat, die dieses Buch nicht beantwortet, findet die Antwort am ehesten dort — und zwar verbindlich, denn was hier steht, ist eine Erklärung, keine Norm.
- modelcontextprotocol.io — Einstieg, Anleitungen und Begriffsklärungen.
- Die Spezifikation — der eigentliche Text, nach Fassungen datiert. Ein Server handelt beim Verbinden aus, welche Fassung gesprochen wird; welche das ist, entscheidet in aller Regel das verwendete SDK und nicht der eigene Code.
- github.com/modelcontextprotocol — die Spezifikation als Repository, mit Änderungsverlauf und Diskussionen. Der Ort, an dem sich abzeichnet, was als Nächstes kommt.
- modelcontextprotocol/ext-tasks — die Tasks-Extension (SEP-2663) mit eigener Spezifikation und eigenem Schema, getrennt vom Kern versioniert (Kapitel 19).
SDK für Go
- modelcontextprotocol/go-sdk — das offizielle SDK. Herausgeber ist die MCP-Organisation selbst, und es steht bei einer stabilen 1.x.
Es gibt weitere Go-Bibliotheken für MCP, teils älter und verbreiteter. Wer neu anfängt, ist mit dem offiziellen besser bedient: vor einer 1.0 darf jede Nebenversion brechen, und bei einem Protokoll, das zwei Seiten sprechen müssen, ist das kein theoretisches Risiko.
Werkzeuge aus diesem Haus
Beide sind aus der Arbeit an eigenen MCP-Servern entstanden — sie lösen Probleme, die in diesem Buch beschrieben werden.
MCP-Tester
Fährt einen fertig gebauten Server über das Protokoll und prüft, was er tatsächlich antwortet. Unit-Tests können das nicht: sie rufen Handler-Funktionen auf, während ein MCP-Server sich mit einer Gegenstelle darüber einigt, welche Werkzeuge es gibt, welche Parameter sie nehmen und was zurückkommt.
Testfälle sind Textdateien:
call_tool markitdown__convert__mlc uri:test.txt
assert_contains "Hello MarkItDown"Wozu das gut ist, zeigt ein Fall aus der Praxis: ein Server bot im Schema einen Parameter an, der ausgelesen und dann verworfen wurde. Kein Test schlug an, weil kein Test ihn je gesetzt hatte. Ein Skript, das jedes angebotene Werkzeug einmal mit jedem angebotenen Parameter aufruft, hätte es gefunden.
- Produktseite: mlcgo.eu/products/mlc-tester
- Quelltext: github.com/hmsoft0815/mlc_mcptester
mlcartifact — Artefaktspeicher
Setzt das Artifact-Pattern um, das Kapitel 13 beschreibt: Server tauschen Daten über Kennungen aus, statt sie durch den Kontext des Modells zu schleifen. Der eine legt ein Ergebnis ab und gibt die ID zurück, der andere holt es sich — das Modell entscheidet, was geschieht, ohne die Daten selbst zu tragen.
Das lohnt sich, sobald Ergebnisse größer werden als eine Antwort: Zeitreihen, Bilder, umgewandelte Dokumente.
- Produktseite: mlcgo.eu/products/mlcartifact
- Quelltext: github.com/hmsoft0815/mlcartifact
wollmilchsau — V8-Sandbox & Deterministisches Rechnen
Setzt das Prinzip „Rechnen statt Denken“ um: Statt teure und fehleranfällige
Reasoning-Tokens für Mathematik, Regex-Parsing oder Datentransformationen zu
verschwenden, bietet wollmilchsau dem Agenten eine hermetisch isolierte
V8-JavaScript/TypeScript-Sandbox. Das Modell formuliert den Code, die Sandbox
berechnet das Ergebnis in Millisekunden mit 100 % mathematischer Exaktheit.
- Produktseite: mlcgo.eu/products/wollmilchsau
- Quelltext: github.com/hmsoft0815/wollmilchsau
Zum Weiterlesen im Buch
- Kapitel 14 — Qualitätssicherung, der Server-Inspector
- Kapitel 13 — das Artifact-Pattern
- Kapitel 16 — Transporte, Streamable HTTP und SSE
- Kapitel 17 — Sicherheit und OAuth 2.1