12 Server, ein Protokoll: Wie MCP meinen Unterricht verändert hat
Angefangen hat alles mit einem Problem: Ich saß sonntagabends vor Moodle und klickte mich durch Menüs. Kurs anlegen. Abschnitt erstellen. Quiz hinzufügen. Fragen eingeben. Für einen einzigen Kurs brauchte ich Stunden. Für fünf Klassen einen halben Sonntag.
Irgendwann dachte ich: Das muss doch auch anders gehen.
Ein Server, ein Problem
Der erste MCP-Server war simpel. Ein kleiner Node.js-Service, der die Moodle-Web-Service-API ansprach. Drei Endpunkte: Kurs erstellen, Quiz erstellen, Fragen hinzufügen. Hinter Traefik als Reverse Proxy, Let's Encrypt für HTTPS, fertig.
An dem Abend, an dem ich zum ersten Mal "Erstelle ein Quiz zum Thema Kaufvertragsstörungen" tippen konnte und 30 Sekunden später ein fertiges Quiz in Moodle hatte, wusste ich: Das wird größer.
Der Anfang war simpel
Drei API-Endpunkte, ein Docker-Container, ein freier Sonntagabend. Mehr braucht es nicht, um anzufangen.
Von 3 auf 73 Tools
Heute hat der Moodle-MCP-Server alleine 73 Werkzeuge. Kurse, Abschnitte, Quizze, H5P-Aktivitäten, Einschreibungen, Noten, Bewertungen, Labels, Seiten, URLs, Ressourcen, Ordner — alles per API. Dazu kommen Bulk-Operationen: moodle_bulk_add_questions legt in einem Aufruf beliebig viele Fragen an. moodle_import_gift importiert Moodles GIFT-Format direkt.
Aber der Moodle-Server war nur der Anfang.
Das Ökosystem
Zwölf Server. Über hundert Werkzeuge. Ein Protokoll.
| Server | Was er tut |
|---|---|
| Moodle-MCP | 73 Tools für die komplette Moodle-Verwaltung |
| WordPress-MCP | Blog-Artikel erstellen, Medien hochladen |
| SharePoint-MCP | Schulinterne Dokumente und Seiten verwalten |
| Teams-MCP | Nachrichten, Meetings, Kalender |
| IMAP-MCP | E-Mails lesen, sortieren, beantworten |
| Voice-MCP | Sprache zu Text (Whisper) und Text zu Sprache (Kokoro) |
| H5P-Preview | Interaktive Lernmodule rendern |
| React-Factory | React-Komponenten on-the-fly erzeugen |
| EduGrow-MCP | Cannabis-Bildungsplattform verwalten |
Jeder Server ist ein eigener Docker-Container. Jeder spricht MCP — das Model Context Protocol. Jeder ist unabhängig deploybar, unabhängig skalierbar, unabhängig ersetzbar.
Die Architektur-Philosophie: Viele kleine unabhängige Server
Warum nicht ein großer Server mit allem? Weil kleine Server besser sind. In jeder Hinsicht.
Fehlertoleranz. Wenn der Voice-Server abstürzt, funktioniert Moodle weiter. Wenn SharePoint ein Update braucht, läuft der Rest.
Entwicklungsgeschwindigkeit. Ich kann den IMAP-Server in einer Stunde umschreiben, ohne irgendetwas anderes anzufassen.
Einfachheit. Jeder Server hat eine Aufgabe. Der Moodle-Server spricht mit Moodle. Der Teams-Server spricht mit Teams. Kein Server muss wissen, was die anderen tun.
Das ist kein Zufall. Das ist Stigmergy — das Prinzip, nach dem auch Ameisen arbeiten. Kein zentraler Koordinator. Jeder Akteur reagiert auf seine Umgebung und hinterlässt Spuren, an denen andere anknüpfen.
Der Sonntagabend-Workflow
Konkret sieht das so aus. Sonntagabend, 20 Uhr. Morgen startet eine neue Lernsituation zum Thema "Beschaffungsprozesse im Großhandel".
Früher hätte ich jetzt drei Stunden vor Moodle gesessen. Heute:
- Ich beschreibe die Lernsituation in natürlicher Sprache
- Claude erstellt den Moodle-Kursabschnitt über den Moodle-MCP
- Quiz-Fragen werden generiert und importiert — 71 Fragen in unter einer Minute
- H5P-Aktivitäten werden erzeugt und hochgeladen — H5P-Pipeline
- Das Ganze wird als Arbeitsblatt im Corporate Design meiner Schule formatiert
- Eine kurze Zusammenfassung geht per IMAP-MCP an meine Fachgruppe
20:45 Uhr. Fertig. Nicht "Entwurf fertig". Alles live in Moodle.
71 Fragen in unter einer Minute
Das ist kein Tippfehler. Die Bulk-API des Moodle-MCP erstellt Multiple-Choice, Wahr/Falsch und Freitext-Fragen in einem einzigen Aufruf. Was früher einen Nachmittag gedauert hat, passiert jetzt während du dir einen Kaffee holst.
Die restliche Zeit des Abends gehört mir. Oder ich nutze sie, um den nächsten MCP-Server zu bauen.
Das Stigmergy-Prinzip
Was dieses System von klassischer Software-Architektur unterscheidet, ist das Prinzip dahinter. In traditionellen Systemen gibt es einen zentralen Koordinator — einen Orchestrator, der sagt, wer wann was tut.
In meinem System gibt es das nicht. Jeder Server existiert für sich. Er bietet Werkzeuge an. Er wartet auf Anfragen. Er weiß nichts von den anderen.
Die Intelligenz sitzt nicht in der Infrastruktur. Sie sitzt im LLM, das die Server nutzt. Claude entscheidet, welche Werkzeuge es für eine Aufgabe braucht, ruft sie in der richtigen Reihenfolge auf und kombiniert die Ergebnisse.
Das ist Stigmergy. Die Umgebung — die verfügbaren Server — strukturiert das Verhalten. Nicht ein Plan. Nicht ein Organigramm. Die Werkzeuge selbst.
Was ich gelernt habe
Ein Jahr mit MCP-Servern hat mir ein paar Dinge beigebracht:
Automatisierung ist kein Luxus. Es ist eine moralische Pflicht. Jede Stunde, die ich mit Klick-Arbeit in Moodle verbringe, ist eine Stunde, die ich nicht für meine Schüler habe.
Perfekt ist der Feind von fertig. Der erste Moodle-Server hatte drei Endpunkte und war nützlicher als jedes kommerzielle Tool, das ich bis dahin gesehen hatte.
Offene Protokolle gewinnen. MCP ist kein proprietäres Format. Jeder kann einen MCP-Server bauen. Jeder kann ihn nutzen. Das macht das Ökosystem robust.
Aber Vorsicht
MCP-Server haben vollen Zugriff auf die Systeme, mit denen sie verbunden sind. Ein falsch konfigurierter Server kann Kurse löschen, Noten überschreiben oder E-Mails verschicken. Rate-Limiting und API-Key-Management sind Pflicht, nicht Kür.
Die beste Dokumentation ist ein funktionierender Server. Niemand liest Dokumentation. Aber wenn du "Erstelle einen Kurs" eintippen kannst und es funktioniert, braucht niemand ein Handbuch.
Wie geht es weiter?
Mehr Server. Mehr Werkzeuge. Mehr Automatisierung. Der nächste Schritt ist ein MCP-Server für Microsoft 365 Administration — Benutzer verwalten, Lizenzen zuweisen, alles was ein Schuladmin tun muss.
Und irgendwann, wenn das Ökosystem groß genug ist, braucht es mich vielleicht gar nicht mehr.
Aber bis dahin sitze ich sonntagabends vor dem Rechner. Nicht mehr, um Moodle-Menüs zu klicken. Sondern um den nächsten Server zu bauen.