Model Context Protocol (MCP) ist im Kern eine standardisierte Schnittstelle, über die ein Modell sicher und strukturiert auf externe Fähigkeiten zugreifen kann. Für das Exam ist wichtig: MCP ist kein Selbstzweck und kein „magischer Performance-Boost“, sondern ein Architekturbaustein. Du setzt MCP dann ein, wenn du Tool-Zugriff wiederverwendbar, kontrollierbar und modellunabhängiger machen willst. Ohne MCP landen Teams oft bei ad-hoc Tool-Integrationen pro Agent oder Prompt-Flow – das funktioniert im Prototyp, wird aber in Produktion schnell unübersichtlich.
Ein gutes Denkmodell: MCP trennt drei Ebenen. Erstens das Modell, das entscheidet, wann ein Tool gebraucht wird. Zweitens den MCP-Server, der beschreibt, welche Tools es gibt und wie sie aufgerufen werden (inklusive Parametern, Fehlern, Limits). Drittens die eigentlichen Backends, z. B. Ticket-Systeme, Datenbanken oder interne APIs. Diese Trennung reduziert Kopplung: Wenn du intern ein Backend tauschst, bleibt die MCP-Tool-Oberfläche stabil. Genau das ist in Architekturfragen ein starkes Argument.
Wann ist MCP besonders sinnvoll? Bei mehreren Agenten oder Workflows, die dieselben Ressourcen brauchen. Beispiel: Support-Agent, Ops-Agent und Reporting-Agent greifen alle auf Incident-Daten zu. Mit MCP definierst du einmal ein konsistentes Tool-Interface statt dreimal ähnlichen Code mit leicht unterschiedlichen Parametern. Ebenso relevant ist MCP bei Governance-Anforderungen: Du kannst zentral festlegen, welche Aktionen erlaubt sind, wie Inputs validiert werden und welche Aufrufe protokolliert werden. Für Prüfungsfragen zu „scale + reliability + auditability“ ist das oft die richtige Begründung.
Wann eher nicht? Wenn du ein kleines, eng begrenztes Einmal-Skript baust, das exakt einen API-Call braucht und keine Wiederverwendung geplant ist. Dort kann direkte Integration schneller sein. Aber: Viele Teams unterschätzen, wie schnell „Einmal-Skripte“ wachsen. In exam-orientierten Antworten punktest du, wenn du den Trade-off benennst: kurzfristige Einfachheit vs. langfristige Wartbarkeit.
Wichtige Architekturkriterien für MCP-Entscheidungen:
Typische Anti-Patterns: Zu viele zu grobe Tools („do_everything“) statt klarer, typisierter Operationen; fehlende Fehlermodellierung; und unklare Berechtigungsgrenzen. Ein MCP-Tool sollte klein genug sein, dass sein Verhalten vorhersagbar bleibt, aber groß genug, um einen sinnvollen Task abzuschließen. Für das Exam zählt dabei die Begründung: weniger Ambiguität, weniger Failure-Surface, bessere Testbarkeit.
Praxisregel für Szenariofragen: Wenn du in der Aufgabenstellung Hinweise auf mehrere Teams, mehrere Agenten, Compliance oder Wachstum siehst, ist MCP oft der bessere Architekturvorschlag. Wenn die Aufgabe klar lokal und kurzlebig ist, kannst du bewusst gegen MCP entscheiden – solange du den späteren Migrationspfad erwähnst.
1. MCP lohnt sich vor allem bei Wiederverwendung, Governance und Skalierung, nicht bei jedem Mini-Prototyp.
2. Die Stärke liegt in der Entkopplung: stabiles Tool-Interface trotz wechselnder Backends.
3. Exam-Score steigt, wenn du Trade-offs explizit machst (Speed heute vs. Wartbarkeit morgen).
Du entwirfst ein System mit drei Agenten (Support, Billing, Ops), die alle auf Kundendaten und Ticketstatus zugreifen. Das Team erwartet schnelles Wachstum und Audit-Pflichten. Sollte der Tool-Zugriff direkt pro Agent integriert oder über MCP standardisiert werden? Begründe kurz.
In diesem Szenario ist MCP klar vorzuziehen, weil mehrere Agenten dieselben Fähigkeiten konsistent nutzen müssen und Audit-Anforderungen einen zentralen Kontroll- und Protokollpunkt verlangen. Direkte Integrationen pro Agent erhöhen Kopplung, Inkonsistenzen und Wartungskosten. MCP schafft ein einheitliches, testbares Interface und vereinfacht spätere Skalierung.