TECHNOLOGIE

MCP

Model Context Protocol

Ein offenes Protokoll, mit dem ein KI-Modell sicher mit externen Tools und Datenquellen verbindet, ohne per-Modell-Custom-Integrationen.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Model Context Protocol (MCP) ist für AI Agents das, was HTTP für das Web ist: ein gemeinsamer, offener Standard dafür, wie das Modell mit dem Rest der Welt spricht. Anthropic hat es Ende 2024 eingeführt; 2025 und 2026 wurde es breit adoptiert.

Die technische Form: Ein MCP-Server stellt Resources, Tools und Prompts über ein definiertes Schema bereit. Jeder MCP-fähige Client (Claude Desktop, Claude Code, die API, ein IDE-Plugin) kann diese Tools entdecken und aufrufen, ohne pro Anbieter Klebstoff zu schreiben. Integration einmal bauen, jeder MCP-Client profitiert.

Beispiel für den Hebel: Eine Firma verpackt ihr internes CRM, ihr Analytics-Warehouse und ihren Dokumentenspeicher als drei MCP-Server. Dieses Quartal ist das Team auf Claude; nächstes Quartal testet es aus Kostengründen ein anderes Modell. Mit Function-Calling, das an einen Anbieter gebunden ist, bedeutet dieser Wechsel, jede Integration neu zu schreiben. Mit MCP zeigt es den neuen Client auf dieselben drei Server und macht weiter. Die Integrationskosten wurden einmal gezahlt, nicht pro Modell. Diese Server mit RAG über den Dokumentenspeicher zu paaren, liefert geerdete Antworten aus internen Daten ohne maßgeschneiderte Verrohrung.

Der ehrliche Trade-off und der Founder-Fehler: MCP ist nur dann die richtige Wahl, wenn du erwartest, Modelle zu wechseln, oder Portabilität willst; bist du dauerhaft bei einem Anbieter, ist schlichtes Function-Calling einfacher und in Ordnung. Das größere Risiko ist Sicherheit. MCP ist ein Transportprotokoll, kein Berechtigungsmodell. Ein schlampiger MCP-Server, der ein schreibfähiges Tool mit schwacher Auth exponiert, ist ein wartender Confused-Deputy-Fehler, bei dem das Modell dazu verleitet wird, etwas aufzurufen, das es nicht sollte. Wir bauen MCP-Server regelmäßig und haben sie in Produktion ausgeliefert; wir schreiben außerdem für jeden ein Security-Review, weil der Standard sich noch bewegt und der Fehlerfall deine internen Systeme sind, nicht ein Chatbot, der etwas Dummes sagt. Wir verpacken ein Tool nur dann in MCP, wenn es innerhalb einer Modell-Schleife wirklich nützlich ist und das Sicherheitsmodell den Aufruf durch ein Modell erlaubt, mit Human-in-the-Loop bei allem Destruktiven.

// FAQ

Häufige Fragen

Function-Calling ist anbieterspezifisch. MCP ist portabel. Wer nie den Modellanbieter wechselt, kommt mit Function-Calling aus. Wer den Anbieter wechseln möchte (die meisten Enterprises wollen das), wählt MCP für geringeren Lock-in.
MCP selbst ist ein Transportprotokoll; Sicherheit hängt davon ab, was der Server exponiert und wie authentifiziert wird. Ein schlecht gebauter MCP-Server ist ein wartender Confused-Deputy-Fehler. Ein gut gebauter ist nicht riskanter als jede andere interne API.
Zwei Kriterien: das zugrundeliegende Tool ist innerhalb einer LLM-Schleife tatsächlich nützlich UND das Sicherheitsmodell erlaubt einem Modell den Aufruf (vorzugsweise mit Human-in-the-Loop bei destruktiven Aktionen). Alles andere bleibt eine reguläre API.