Model Context Protocol (MCP)

Wofür MCP da ist

Vor einem gemeinsamen Protokoll war jede Paarung aus Assistent und Werkzeug eine eigene Integration, zweimal geschrieben und für immer gepflegt: fünf Assistenten und zwanzig Werkzeuge bedeuteten hundert maßgeschneiderte Verbindungen. MCP macht daraus eine Addition statt einer Multiplikation. Wer ein Werkzeug baut, schreibt einen Server, wer eine Anwendung baut, schreibt einen Client, und alles auf der einen Seite kann mit allem auf der anderen sprechen. Anthropic veröffentlichte es Ende 2024 als offenen Standard, und es wurde seither weit darüber hinaus übernommen. Vom Geist her ähnelt es eher einer Gerätetreiber-Schnittstelle als einer Produkt-API: Der Wert liegt nicht darin, was es kann, sondern darin, dass sich alle auf die Form geeinigt haben.

Der Aufbau ist Client-Server. Die Anwendung, die das Modell hält, ist der Client; jede Fähigkeit, die Sie bereitstellen wollen, läuft als Server, der maschinenlesbar beschreibt, was er anbietet, damit das Modell die Optionen sieht und wählt. Es ist transportunabhängig — ein Server kann ein lokaler Prozess auf derselben Maschine sein oder etwas, das über HTTP erreichbar ist —, weshalb dieselbe Integration in einem Desktop-Assistenten, in einem auf einem Server laufenden KI-Agenten und in einem Programmierwerkzeug funktioniert, ohne für jedes neu geschrieben zu werden.

Was ein Server bereitstellt

Ein Server bietet drei Arten von Dingen an, und die Unterscheidung zählt, wenn Sie selbst einen bauen:

• Werkzeuge — Aktionen, die das Modell auslösen kann: eine Nachricht senden, eine Tabelle abfragen, einen Datensatz anlegen. Das sind die mit Folgen und die, bei denen Vorsicht angebracht ist.
• Ressourcen — Daten, die der Client in den Kontext holen kann: eine Datei, ein Dokument, eine Zeile, der Inhalt einer Seite. Lesbares Material, das dem Modell gegeben wird, nicht etwas, das es tut.
• Prompts — wiederverwendbare, parametrisierte Anweisungen, die ein Mensch bewusst auswählt, statt etwas, wonach das Modell von sich aus greift.

Was das Protokoll nicht löst

Ein Verbindungsstandard beseitigt die Klempnerarbeit und lässt alles Schwierige stehen. Das Erste, was in der Praxis auffällt: Werkzeuge zu haben ist nicht kostenlos. Jede Fähigkeit, die ein Modell aufrufen kann, muss ihm beschrieben werden, und diese Beschreibungen belegen denselben begrenzten Kontext wie die eigentliche Arbeit, sodass ein großer Katalog leise mit der Aufgabe konkurriert. Genau darauf sind wir beim Bau von Agenten für Kundinnen und Kunden bei AgentCeres — dem KI-Growth-Officer auf agentceres.com — gestoßen: Ab einer gewissen Zahl verfügbarer Fähigkeiten muss der Katalog zusammengefasst werden, damit er überhaupt hineinpasst, was bedeutet, dass jede zusätzliche Integration etwas kostet, selbst wenn sie niemand nutzt. Die technische Disziplin besteht am Ende darin, zu entscheiden, was ein Agent *nicht* erreichen können soll.

Die zweite Lücke ist die Befugnis. Das Protokoll beschreibt, wie ein Werkzeug aufgerufen wird; es sagt nichts darüber, ob dieser Agent, handelnd für diese Kundin, gerade jetzt, das dürfen sollte. Ein Werkzeug, das eine Tabelle liest, und eines, das im Social-Account eines Unternehmens veröffentlicht, sind für das Protokoll identisch und für das Geschäft völlig verschieden. Diese Grenze gehört in Ihr eigenes Produkt, weshalb bei uns alles mit öffentlicher Folge hinter einem Freigabe-Gate mit einem Menschen davor wartet, ganz gleich, wie die Fähigkeit angebunden wurde.