Kurs
Skalierbare agentische Systeme entwickeln
1 Std. 30 Min.
16K
Vor anderthalb Jahren war das Model Context Protocol außerhalb von Anthropic noch ein Nischenthema. Heute taucht es in Interviews für AI Engineering, Developer Relations und Backend-Rollen auf, weil viele Teams, die Agents ausliefern, irgendwo im Stack einen MCP-Server oder -Client haben.
MCP (Model Context Protocol) ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen mit externen Tools, Daten und Prompt-Vorlagen verbunden werden. Es löst das N×M-Integrationsproblem: Ohne gemeinsames Protokoll braucht jedes Model-Tool-Paar seinen eigenen Connector. Mit MCP baust du den Connector einmal, und jeder konforme Host kann ihn nutzen. Man hört dafür manchmal „das USB‑C der KI" — als Einstieg okay, aber nicht viel mehr.
Welche Fragen gestellt werden, hängt stark von der Rolle ab. Ein Junior-Developer sollte Tools versus Resources erklären können. Eine Platform Engineer wird eher gefragt, wie ein zustandsloser Protokollkern das Deployment verändert. Der Guide ist nach Schwierigkeit und Use Case aufgebaut — konzentriere dich auf die Abschnitte, die zu deiner Rolle passen.
Timing ist hier wichtig, und ich sage das ausdrücklich, weil MCP sich noch verändert. Zum Zeitpunkt des Schreibens ist die aktuelle stabile Spezifikation 2025-11-25. Ein Release Candidate für 2026-07-28 ist eingefroren und soll in etwa vier Wochen erscheinen, daher ist alles aus diesem RC als zukunftsgerichtet markiert.
MCP-Interviewfragen für Einsteiger
Diese Fragen kommen in vielen Screens vor, unabhängig vom Senioritätslevel. Ich würde mit dem Vokabular anfangen.
Was ist MCP und warum wurde es entwickelt?
MCP ist ein offener Standard, ursprünglich von Anthropic entwickelt und im November 2024 als Open Source veröffentlicht, um KI-Anwendungen mit externen Tools und Datenquellen zu verbinden. Direkt gesagt: Implementiere MCP einmal, und du kannst mit jedem MCP‑kompatiblen Server sprechen, statt für jedes Tool einen neuen Connector zu schreiben.
Was ist ein MCP-Server?
Ein Server ist ein Programm, das Tools, Ressourcen und Prompts für einen MCP-Client bereitstellt. Er kann lokal als Subprozess über stdio laufen oder als eigenständiger Remoteprozess über HTTP erreichbar sein. Der Server weiß nichts über das Modell selbst; er beantwortet Anfragen gemäß Protokoll.
Was ist ein MCP-Client?
Der Client ist der Protokoll-Connector innerhalb einer Host-Anwendung (z. B. Claude Desktop, VS Code oder Cursor) und spricht jeweils mit genau einem Server über JSON-RPC. Ein Host kann mehrere Clients starten, wobei jeder Client seine eigene 1‑zu‑1‑Verbindung zu einem Server hält.
Worin unterscheidet sich MCP von einer normalen REST-API?
Eine REST-API wird dafür geschrieben, dass Entwickler sie aus Code aufrufen. MCP ist dafür gebaut, dass ein LLM sie zur Laufzeit entdeckt und aufruft. Diese Unterscheidung ist wichtiger als das Drahtformat. Ein Client kann den Server nach tools/list fragen und eine strukturierte Beschreibung der verfügbaren Fähigkeiten erhalten — etwas, das eine typische REST-API nicht standardmäßig bietet. Für eine einfache Integration ist ein direkter API-Call oft schneller und günstiger.
Welche Arten von Ressourcen kann ein Server bereitstellen?
Alles, was per URI adressierbar ist: Dateien, Datenbankeinträge, Dokumente, Konfigurationswerte, API-Antworten. Ressourcen sind schreibgeschützter Kontext, keine Aktionen — eine häufige Anfängerfalle.
Interviewfragen zu zentralen MCP-Konzepten
Sitzt das Vokabular, fragen Interviewer meist nach dem Zusammenspiel der Bausteine.
Wie sieht die High-Level-Architektur aus?
Drei Rollen: Host, Client, Server. Der Host ist die Anwendung, die eine Person nutzt. Er instanziiert einen oder mehrere Clients, und jeder Client hält eine einzige Verbindung zu einem Server. Jede Nachricht zwischen Client und Server ist JSON-RPC 2.0 — das liefert ein stabiles Drahtformat unabhängig vom Transport.
Was sind die drei Lebenszyklusphasen einer Verbindung?
Initialisierung, Betrieb und Herunterfahren. In der Initialisierung sendet der Client seine unterstützte Protokollversion und Fähigkeiten, der Server antwortet mit seinen. Sobald beide Seiten sich einig sind, laufen normale Requests wie tools/list und tools/call in der Betriebsphase. Herunterfahren ist nur ein sauberes Schließen.
Welche Transporte nutzt MCP heute?
stdio für lokale, Subprozess-basierte Server und Streamable HTTP für Remote-Server. Streamable HTTP hat im Spec 2025-03-26 den älteren HTTP-plus-SSE-Transport ersetzt — zwei separate SSE-Endpunkte zu beschreiben ist also bereits veraltet.
Was ist der echte Unterschied zwischen Tools, Ressourcen und Prompts?
Die Unterscheidung betrifft Kontrolle, nicht Datentypen:
- Tools liegen in der Kontrolle des Modells. Das LLM entscheidet kontextabhängig, wann es eines aufruft.
- Ressourcen liegen in der Kontrolle der Anwendung. Host oder Nutzer entscheiden, wann sie geladen werden.
- Prompts liegen in der Kontrolle des Nutzers. Eine Person wählt vor der Inferenz explizit eine Vorlage aus.
Viele Kandidatinnen und Kandidaten definieren das über die Datenart — damit verfehlt man den Kern.
Interviewfragen zu MCP-Tools, Ressourcen und Prompts
Wenn das Steuerungsmodell sitzt, geht es darum, wie diese Primitiven in der Praxis aussehen.
Was umfasst eine Tool-Definition?
Einen name, eine description, ein inputSchema in JSON Schema und seit dem Spec 2025-06-18 optional ein outputSchema plus annotations, die Verhalten beschreiben, etwa ob ein Tool read-only oder destruktiv ist. Clients sollten Annotations als unzuverlässig behandeln, sofern sie nicht von einem vertrauenswürdigen Server stammen. Es sind Hinweise, keine Garantien.
Wann sollte etwas ein Tool statt einer Ressource sein?
Wenn es Nebeneffekte hat oder eine frische, Live-Berechnung braucht, ist es ein Tool. Wenn es statische oder halb-statische Referenzdaten ohne Nebeneffekte sind, ist es eine Ressource. Eine Wetterabfrage gegen eine Live-API ist ein Tool. Eine gecachte Liste unterstützter Städte ist eine Ressource.
Was macht ein gutes MCP-Tool aus — über „es funktioniert" hinaus?
Designe es danach, was der Nutzer erledigen will — nicht nach den Endpunkten, die zufällig existieren. Ein Tool sollte einen kompletten Workflow kapseln, nicht nur einen einzelnen rohen API-Call. Wichtig ist auch die Beschreibung: Dieser Text landet im Kontext des Modells und beeinflusst, ob es das richtige Tool wählt. Hier ein Minimalbeispiel mit der Python-SDK-Schicht FastMCP:
from mcp.server.fastmcp import FastMCP
app = FastMCP("weather-demo")
@app.tool()
async def get_weather(city: str) -> str:
"""Get the current weather for a city."""
return f"Weather data for {city}"
@app.resource("config://units")
async def get_units() -> str:
"""Static configuration for the unit system in use."""
return '{"temperature": "celsius"}'Die Docstring des Tools wird zur Beschreibung; die Ressource ist statische, per URI zugängliche Daten ohne Nebeneffekte.
Wie ruft ein Client eine Ressource ab?
Er ruft resources/read für eine URI auf, die er zuvor über resources/list erhalten hat. Unterstützt der Server die Fähigkeit listChanged, kann er den Client informieren, wenn sich die Ressourcenliste ändert. Ohne diese Fähigkeit hat der Client kein Signal und muss pollen oder manuell aktualisieren.
Interviewfragen zur MCP-Serverentwicklung
Hier muss sich Konzeptwissen in laufenden Code verwandeln.
Welche offiziellen SDKs gibt es, und sind sie alle gleich ausgereift?
Nein. Die SDKs sind gestaffelt: TypeScript, Python, C# und Go sind Tier 1 mit vollem Funktionsumfang, Java und Rust sind Tier 2, und Swift, Ruby, PHP und Kotlin sind Tier 3. Das Python-SDK beinhaltet FastMCP, die dekoratorbasierte Server-API.
Was ist der häufigste Bug, der einen lokalen Server zerschießt?
Auf stdout schreiben, wenn du es nicht solltest. Ein stdio-Transport nutzt stdout ausschließlich für JSON-RPC-Nachrichten, daher zerlegt ein verirrtes print() oder console.log() den Nachrichtenstrom und der Parser des Clients stolpert. Alles, was du fürs Debugging loggen willst, muss stattdessen auf stderr.
MCP Inspector zeigt Tool und Ressource. Video von der Autorin/dem Autor.
Wie funktioniert Fehlerbehandlung in MCP und warum ist das im Interview wichtig?
Es gibt drei Ebenen. Transportfehler sind Verbindungsprobleme. Protokollfehler nutzen die Standardcodes von JSON-RPC (-32700 für Parse Error, -32600 bis -32603 für ungültige Requests, unbekannte Methoden usw.). Anwendungsfehler — etwa wenn ein API-Call in deinem Tool fehlschlägt — sollten mit isError: true im Tool-Result zurückkommen, damit das Modell sie erkennt und darauf reagieren kann.
return {
"content": [{"type": "text", "text": "Rate limit exceeded, try again later"}],
"isError": True
}Dieses Flag lässt das Modell den Fehler sehen und etwas anderes versuchen.
Ist MCP aktuell zustandsbehaftet?
Ja, Sessions werden heute auf Verbindungsebene nachgehalten. Das erzeugt Skalierungsprobleme in der Produktion, die ich im Abschnitt Systemdesign behandle.
Interviewfragen zu MCP-Sicherheit und Governance
Sicherheitsfragen gehören inzwischen in vielen MCP-Interviews dazu, besonders für Platform- und Enterprise-Rollen.
Wie unterscheidet sich Authentifizierung zwischen stdio- und HTTP-Transporten?
Für lokale stdio-Server ist Authentifizierung in der Praxis optional; du vertraust dem Prozess ja bereits, den du gestartet hast. Für HTTP-basierte Remote-Server ist OAuth 2.1 der Rahmen, und Server gelten laut Spec vom 2025-06-18 als OAuth‑2.0‑Resource-Server. OAuth ist in MCP nicht überall Pflicht.
Was ist Tool Poisoning?
Bösartige Anweisungen, die in der Metadatenbeschreibung eines Tools versteckt sind, meist in Description oder Schema, die das Modell beim Entscheiden liest, welches Tool es aufruft. Das Tool muss dafür nicht einmal ausgeführt werden, weil das Modell die Anweisungen schon beim Auflisten gesehen hat.
Worin unterscheidet sich ein Rug-Pull-Angriff von Tool Poisoning?
Tool Poisoning ist ein Problem am Einstieg. Rug Pull ist ein Persistenzproblem: Ein Tool wirkt bei der Freigabe sauber, dann ändert sich seine Definition später, und die meisten Clients haben keinen eingebauten Zwang zur erneuten Freigabe. Gegen das eine zu verteidigen, schützt nicht automatisch vor dem anderen.
Was ist Enterprise-Managed Authorization und warum ist das gerade wichtig?
EMA ist eine MCP-Erweiterung, die am 18. Juni 2026 stabil wurde. Sie verlagert die Autorisierungsentscheidung zum Identitätsanbieter der Organisation statt auf einzelne Zustimmungs-Klicks pro Server und Mitarbeiter. Der Client erhält beim Single Sign-on ein signiertes Identity Assertion JWT und tauscht es beim Authorization Server des Servers gegen ein Scoped Access Token. Anthropic, Microsoft und Okta unterstützen es.
Interviewfragen zu MCP und KI-Agents
Hier trifft das Protokoll auf das Agent-Design.
Warum ist MCP speziell für Agents relevant?
Agents brauchen Kontext und Aktionen. MCP packt beides in ein Protokoll. Wie oben erwähnt, ermöglicht tools/list, dass ein Agent Angebote entdeckt, statt sich auf eine hartkodierte Liste im Agent-Code zu verlassen.
Modell aus Agent-Host, -Client und -Server. Bild von der Autorin/dem Autor.
Was ist der Unterschied zwischen MCP und A2A?
Kurzregel: MCP verbindet Agents mit Tools, A2A verbindet Agents miteinander. Beide Protokolle liegen inzwischen unter der Agentic AI Foundation und werden üblicherweise als getrennte Schichten betrachtet, nicht als Konkurrenten.
Was ist das Sampling-Primitive und sollte ich es noch erwähnen?
Sampling erlaubt es einem Server, über den Client eine Modellcompletion anzufordern — so kann ein Server agentenähnliches Verhalten ausführen, ohne API-Schlüssel zu halten. Kenne das Primitive, aber mit Caveat: Der RC 2026-07-28 markiert Sampling, Roots und Logging gemäß neuer Feature-Lifecycle-Policy als deprecated. Sie bleiben mindestens zwölf Monate funktional, aber Server-Autoren sollen zunehmend direkt die API eines Modellanbieters aufrufen.
Wie vermeiden Agents, dass Tool-Definitionen das Kontextfenster sprengen?
Indem sie nicht alle Tool-Definitionen vorab laden. Anthrophics Tool-Search-Ansatz lädt Schemas erst bei Bedarf nach; der Engineering-Artikel berichtet über 85 % weniger Tokenverbrauch in toollastigen Setups, bei voller Verfügbarkeit der Tool-Bibliothek. Im Interview würde ich verzögertes Laden mit eng zugeschnittenen Servern kombinieren.
Interviewfragen zum MCP-Systemdesign
Szenariofragen prüfen, ob du Ideen unter Randbedingungen anwenden kannst — nicht nur Definitionen aufsagen.
Entwirf ein Dokumentenabrufsystem mit MCP.
MCP und RAG konkurrieren hier nicht. RAG übernimmt die vorab indizierte Vektor-Retrieval; MCP exponiert diese Retrieval-Funktion als Tool oder Ressource, die der Agent live aufrufen kann — neben allen anderen Aktionen, die er braucht. Beantworte die Frage als Zusammenspiel beider Bausteine, nicht als Entweder-oder.
Entwirf einen MCP-Server für interne Firmendaten.
Starte mit Single Responsibility: Ein Server pro Domäne — z. B. ein Datenbankserver und ein separater Fileserver — statt ein Server für alles. Füge von Anfang an OAuth 2.1, Least-Privilege-Scopes pro Tool und Audit-Logging hinzu, denn Zugriffskontrolle ist im Nachhinein schwerer zu beheben.
Wie skalierst du heute ein MCP-Deployment, bevor der zustandslose Spec live ist?
Viele stolpern hier, indem sie den zukünftigen Spec darstellen, als wäre er schon live. Die Zustandsbehaftung aus dem Server-Abschnitt ist das Skalierungsthema: Horizontale Skalierung braucht Sticky Routing, einen geteilten Session-Store oder ein MCP-Gateway. Der RC 2026-07-28 entfernt Protokoll-Sessions — aber das ist noch nicht live.
Wie verhinderst du in einem großen Multi-Server-Setup, dass das Modell in Tokens ertrinkt?
Das verzögerte Laden aus dem Agent-Abschnitt hilft hier ebenfalls. Auf Deployment-Ebene gilt: Filtern und aggregieren serverseitig, bevor Daten in den Modellkontext gelangen, und alles mit Listen paginieren. Hauptregel: Kontrolle darüber, was ins Kontextfenster gelangt.
Interviewfragen zur MCP-Integration
Integrationsfragen prüfen, ob du weißt, wo MCP in gängigen Entwickler-Tools auftaucht.
Wie zeigt sich MCP in den Claude-Produkten?
Claude.ai, Claude Desktop und Claude Code unterstützen MCP, und Anthropic betreibt ein Connector-Verzeichnis mit vorgefertigten Servern. Es gibt außerdem einen MCP-Connector in der Messages API für Remote-Server — zum Zeitpunkt des Schreibens noch in Beta.
Claude Desktop mit verbundenem MCP-Server. Bild von der Autorin/dem Autor.
Ist MCP nur mit Claude sinnvoll?
Nein. OpenAI hat MCP ab März 2025 in seinem Agents SDK und Apps SDK übernommen. VS Code hat Mitte 2025 die komplette Spec unterstützt, Cursor unterstützt MCP über mcp.json, und Google Cloud hatte bis April 2026 mehr als 50 gemanagte MCP-Server allgemein verfügbar oder in Preview.
Wie unterscheidet sich MCP konkret von RAG?
Kurzfassung des Systemdesigns: RAG antwortet aus einem geplanten Wissensspeicher, MCP übernimmt Live-Lookups und Aktionen.
Fortgeschrittene MCP-Interviewfragen
Fortgeschrittene Fragen prüfen, ob du die Protokollentwicklung verfolgst — nicht nur, wie es heute funktioniert.
Kannst du den Versionsverlauf der Spec durchgehen?
Interviewer fragen das, um zu sehen, was sich geändert hat und wann. Fünf Revisionen sind wichtig, und nur eine ist noch spekulativ:
|
Version |
Datum |
Änderungen |
|
2024-11-05 |
Nov 2024 |
Erste Veröffentlichung |
|
2025-03-26 |
Mär 2025 |
Streamable HTTP ersetzt HTTP+SSE; OAuth 2.1 eingeführt |
|
2025-06-18 |
Jun 2025 |
Strukturierte Tool-Outputs, Elicitation, OAuth-Resource-Server-Klassifizierung |
|
2025-11-25 |
Nov 2025 |
Aktuelle stabile Spec; Async Tasks (experimentell), Governance formalisiert |
|
2026-07-28 |
RC eingefroren Mai 2026 |
Zustandsloser Kern, MCP Apps, Erweiterungs-Framework |
Wichtig ist zu wissen, welche Zeile tatsächlich ausgeliefert wurde.
Wer steuert MCP jetzt tatsächlich?
Anthropic hat das Protokoll am 9. Dezember 2025 an die Agentic AI Foundation (ein gerichteter Fonds unter der Linux Foundation) übergeben. Block und OpenAI haben die AAIF gemeinsam mit Anthropic gegründet, mit Google, Microsoft, AWS, Cloudflare und Bloomberg als unterstützenden Mitgliedern. Die Maintainer behielten die technische Entscheidungsgewalt; die Governance wechselte in eine breitere Stiftung.
Was ändert sich konkret im Release 2026-07-28?
Hauptsächlich der zustandslose Kern aus dem Systemdesign-Abschnitt: Der initialize/initialized-Handshake und der Mcp-Session-Id-Header entfallen, stattdessen reisen Fähigkeitsinformationen in _meta bei jeder Anfrage mit. Das entfernt die Notwendigkeit für Sticky Routing. Ein Erweiterungs-Framework definiert zudem, wie optionale Fähigkeiten wie MCP Apps und Tasks eigenständig ausgeliefert und stabilisiert werden.
Was sind MCP-Erweiterungen und funktionieren sie überall?
Nein. Erweiterungen sind optionale Fähigkeiten wie Enterprise-Managed Authorization, OAuth Client Credentials für Machine-to-Machine-Auth und MCP Apps für interaktive UI im Host. Die Unterstützung variiert je nach Client — designe nicht mit der Annahme einer universellen Unterstützung.
Szenariobasierte MCP-Interviewfragen
Hier zählt diagnostisches Denken mehr als auswendig gelernte Fakten. Strukturiere Antworten als Weg von Symptom über Ursache zur Lösung.
Tool-Aufrufe schlagen sporadisch fehl. Was prüfst du zuerst?
Prüfe, ob die Fehler als isError: true im Tool-Result zurückkommen oder als Protokollfehler. Das zeigt, ob das Problem in der Tool-Logik liegt oder im Transport. Danach Rate Limits der gekapselten Systeme prüfen und Timeouts ausschließen, bevor du ein Modellproblem annimmst.
Ein Agent arbeitet immer wieder mit veralteten Ressourcendaten. Warum?
Zurück zur Ressourcenfrage: listChanged signalisiert dem Client, dass sich Ressourcen geändert haben. Ohne diese Deklaration hat der Client kein Signal und liefert einen gecachten Snapshot, bis etwas ein Refresh erzwingt.
Ein MCP-Server ist zum klaren Engpass geworden. Dein Move?
Entlang Domänengrenzen aufteilen, Connection-Pooling einführen und horizontal skalieren. Bis der zustandslose Kern live ist, brauchst du eventuell weiterhin die im Systemdesign erwähnte Session-Affinität.
Über einen Tool-Aufruf sind sensible Daten abgeflossen. Wie konnte das passieren?
Zwei häufige Ursachen: Ein Tool mit breiteren Rechten als nötig oder fehlende Output-Sanitization, bevor Daten in den Modellkontext gelangen. Abhilfe: Least Privilege pro Tool und ein Sanitization-Schritt vor dem Kontext. Verwandt ist Tool Poisoning: Ein Modell kann angewiesen werden, Daten weiterzuleiten, ohne dass jemand Exfiltrationscode schreibt.
Häufige Fehler in MCP-Interviews
Einige Muster tauchen so oft auf, dass man sie direkt nennen sollte:
-
MCP nach der oben beschriebenen REST-Unterscheidung als Drop-in-REST-Ersatz behandeln
-
Tools versus Ressourcen über Datentypen definieren, obwohl das Steuerungsmodell bereits erklärt wurde
-
Annehmen, dass für
stdiound HTTP dieselbe Auth-Regel gilt -
Die Legacy-SSE-Antwort geben, obwohl der Transportwechsel oben bereits behandelt wurde
-
Die ausgelieferte Spec mit dem RC 2026-07-28 vermischen
-
Die oben genannten Sicherheitsrisiken weglassen, wenn du ein Tool-Calling-System entwirfst
Die meisten dieser Fehler stammen aus älteren Tutorials.
Wie du dich auf MCP-Interviews vorbereitest
Hands-on-Praxis ist bei diesem Protokoll entscheidend.
-
Baue einen kleinen Server mit FastMCP oder dem TypeScript-SDK, exponiere ein Tool und eine Ressource und bringe ihn zum Laufen
-
Installiere den offiziellen Inspector (
npx @modelcontextprotocol/inspector) und sieh dir den rohen JSON‑RPC‑Traffic an -
Verbinde deinen Server mit einem echten Client — Claude Desktop, VS Code oder Cursor — und beobachte den Initialisierungs-Handshake
-
Lies das tatsächliche Spec‑Changelog statt einer Zweitquelle — besonders die Einträge 2025-06-18 und 2025-11-25
-
Wähle ein Systemdesign-Szenario aus diesem Artikel und schreibe vor deinem Interview eine vollständige Antwort
Diese Schritte trennen Definitionswissen von echter Praxiserfahrung.
Fazit
Nur MCP-Definitionen zu pauken reicht nicht mehr. Schwieriger ist, die richtige Antwort der richtigen Spec-Version zuzuordnen. Aktuelle Deployments arbeiten noch mit verbindungsbasierten Sessions; der RC 2026-07-28 weist auf einen zustandslosen Kern. Wenn du beides vermischst, klingt deine Architekturantwort selbstbewusst, aber nicht korrekt.
Deshalb würde ich MCP als etwas behandeln, das man testet — nicht nur liest. Baue den kleinen Server aus dem Vorbereitungsteil, sieh zu, wie ein Client Tools auflistet und Ressourcen liest, und achte darauf, wo das Protokoll endet und dein Applikationsdesign beginnt. Die nützliche Interviewantwort ist nicht „MCP ist das USB‑C der KI." Sondern: „Das standardisiert MCP, das nicht — und das hat sich gerade geändert."
Für einen strukturierten Deep Dive deckt unser Kurs Building Scalable Agentic Systems MCP und A2A im Kontext von Agent-Design, Testing und Deployment ab.
Muss ich jedes Spec-Datum auswendig lernen?
Sampling wird deprecaten. Lohnt es sich trotzdem, es zu lernen?
Mit welchem SDK sollte ich starten, wenn ich MCP noch nie benutzt habe?
Wird MCP nach dem Spec 2026-07-28 noch wichtig sein?
Wie technisch werden Einsteiger-Interviews zu MCP wirklich?
Themen
