MCP in der Praxis: Wann ein Model-Context-Protocol-Server sich lohnt
Das Model Context Protocol ist mehr als ein Akronym im Hype-Zyklus - aber nicht jede Integration verdient einen eigenen MCP-Server. Wann sich der Aufwand auszahlt und wann ein einfaches Skript reicht.
Anderthalb Jahre nach der Veröffentlichung des Model Context Protocols hat sich das Ökosystem sortiert. Erste Server laufen produktiv, andere wurden stillschweigend wieder abgeschaltet. Was bleibt, ist eine Frage, die in jeder Roadmap-Diskussion zu KI-Werkzeugen wiederkehrt: brauchen wir einen eigenen?
Was MCP eigentlich macht
Das Model Context Protocol ist ein Vertrag zwischen Agent und Werkzeug. Statt dass jeder Agent (Claude Code, Cursor, OpenCode, eigene Implementierungen) seinen eigenen Tool-Calling-Stil mit eigenem Schema mitbringt, sprechen alle dieselbe Sprache: standardisierte Tool-Definitionen, Resource-URIs, Prompts. Ein einmal geschriebener Server ist von beliebigen kompatiblen Agenten nutzbar.
Das ist kein revolutionärer Inhalt - es ist ein gut geschriebener Adapter. Der Wert liegt in der Mehrfach-Nutzbarkeit.
Drei Kriterien für einen eigenen MCP-Server
Aus unseren letzten Projekten kristallisieren sich drei Bedingungen heraus, unter denen sich ein eigener Server lohnt:
- Mindestens zwei Konsumenten. Wenn nur ein einziger Workflow das Werkzeug nutzt, ist ein Skript billiger. Erst der zweite Agent (oder Mensch in einer anderen IDE) zahlt die MCP-Investition zurück.
- Stabile Tool-Oberfläche. Eine Funktion, deren Signatur sich monatlich ändert, taugt nicht für ein Protokoll mit Versionsvertrag. MCP belohnt klare, nicht zu fein geschnittene Tools.
- Compliance- oder Logging-Anforderung. Sobald Zugriffe nachvollziehbar oder policy-geprüft sein müssen, ist der zentrale Server der bessere Ort als verstreute Plugins. Dort kann eine OPA-Schicht oder ein Audit-Log einmal sauber implementiert werden.
Drei Anti-Indikatoren
Genauso klar lässt sich beschreiben, wann ein eigener Server Overengineering ist:
- Einmalige Migration oder ETL-Job. Wer ein Skript dreimal laufen lässt und dann archiviert, sollte kein Protokoll-Schema pflegen.
- Eigener UI-Pfad existiert. Wenn das Werkzeug primär durch Menschen über eine Web-UI bedient wird, ist die zusätzliche MCP-Oberfläche nur eine zweite Front, die mitgepflegt werden muss.
- Nur eine Datenquelle, nur ein Agent. In diesem Fall reicht ein Funktionsaufruf im Agent-Skill - die Komplexität eines eigenen Servers zahlt sich nicht aus.
Praxisbeispiel: Wann wir MCP empfehlen
Bei einem aktuellen Mandanten lebten Kundendaten in einer ERP-Datenbank, Verträge in einem DMS, Verfügbarkeiten im Kalender. Drei Quellen, sechs Agent-Workflows, drei Personen, die jeweils mit eigenem Tooling arbeiten. Ein zentraler MCP-Server, der die drei Quellen anzapft und über OPA absichert, war hier deutlich günstiger als sechs einzelne Integrationen.
Bei einem anderen Mandanten ging es um einen einzelnen Dokumenten-Klassifikator für die Eingangspost. Ein klassisches Python-Skript mit Cronjob hat den Job in einer Woche gemacht - MCP hätte nichts hinzugefügt.
Die einfache Faustregel
Erst wenn das zweite "wäre toll, wenn das auch ein anderer Agent nutzen könnte" auf dem Tisch liegt, lohnt sich der Sprung. Vorher ist MCP eine Lösung, die ihr Problem noch sucht.