Vor USB brachte jedes Peripheriegerät sein eigenes Kabel und seinen eigenen Treiber mit. Drucker hatten den einen Stecker, Scanner einen anderen, und ein neues Gerät anzuschliessen hiess hoffen, dass jemand Software für die eigene Maschine geschrieben hatte.
Die KI-Tool-Integration verbrachte ihre ersten paar Jahre in exakt diesem Zustand — und das Model Context Protocol ist die Antwort darauf.
Das Problem, für das es existiert
Ein Agent ist nur so nützlich wie die Dinge, die er erreichen kann. Sie zu erreichen hiess: eine massgeschneiderte Integration für jede Kombination schreiben — dieses Agent-Framework, jene API, in dieser Sprache — und jede war Einzelanfertigung.
Mit einer Handvoll Werkzeuge ist das mühsam. Mit Hunderten ist es unhaltbar — und die Arbeit landet im Müll, sobald man das Framework wechselt.
MCP dreht das Problem um. Statt dass jeder Agent jede Integration implementiert, legt ein Dienst seine Fähigkeiten einmal in einer Standardform offen, und jeder MCP-sprechende Agent kann sie nutzen. Den Server einmal schreiben; jeder Client bekommt ihn gratis.
Das ist die ganze Idee. Ihr Wert kommt aus der Verbreitung, nicht aus Raffinesse — weshalb die interessante Frage nie technisch war.
Was ein MCP-Server tatsächlich offenlegt
Drei Dinge — und der Unterschied zwischen ihnen zählt mehr, als es zuerst scheint.
Tools sind Aktionen, die der Agent auslösen kann — eine Rechnung anlegen, Bestellungen durchsuchen, eine Nachricht senden. Jedes hat einen Namen, eine Beschreibung und ein typisiertes Eingabeschema. Die Beschreibung ist keine Dokumentation; sie ist die Grundlage, auf der das Modell entscheidet, ob es das Ding aufruft — und damit der Text mit dem grössten Hebel in Ihrem Server.
Resources sind lesbarer Kontext — ein Dokument, eine Konfigurationsdatei, ein Datenbankeintrag. Der Agent liest sie, er handelt nicht auf ihnen. Sie füllen das Kontextfenster, statt die Welt zu verändern.
Prompts sind wiederverwendbare Vorlagen, die ein Server für häufige Aufgaben anbietet, damit ein Client sie als fertige Abläufe präsentieren kann.
Die meisten Server bestehen überwiegend aus Tools. Die Aufteilung richtig zu treffen zählt, weil Tools Nebenwirkungen implizieren und Resources nicht — und Clients sie unterschiedlich behandeln, wenn sie entscheiden, was die Freigabe eines Menschen braucht.
Abb. — Der Punkt ist nicht das Protokoll. Der Punkt ist, aus einem N×M-Problem ein N+M-Problem zu machen.
Warum die Verbreitung so schnell ging
Standards scheitern normalerweise. Dieser verbreitete sich aus ein paar praktischen Gründen schnell.
Er kam mit funktionierenden Implementierungen statt mit einer Spezifikation und guten Absichten. Referenz-Server für gängige Systeme existierten am ersten Tag — die erste Frage eines Entwicklers wurde also durch Ausprobieren beantwortet.
Er ist absichtlich klein. Das Protokoll versucht keine Authentifizierungsschemata, keine Geschäftslogik, keine Orchestrierung — es beschreibt, wie ein Client Fähigkeiten entdeckt und aufruft, und hört dann auf. Kleine Standards werden übernommen; umfassende werden debattiert.
Und die Anreize passen für alle. Wer eine API betreibt, macht sein Produkt mit einem MCP-Server aus jedem Agenten heraus nutzbar, den irgendjemand baut — Distribution, die man nicht verhandeln musste. Für Agenten unerreichbar zu sein wird still zu einem Wettbewerbsproblem.
Sollten Sie einen bauen?
Die ehrliche Antwort für die meisten Teams: ja, wenn Sie bereits eine ordentliche API haben — und es ist ein kleineres Projekt, als Sie erwarten.
Ein MCP-Server ist eine dünne Schicht über dem, was Sie ohnehin anbieten. Ist Ihre REST- oder GraphQL-API gut entworfen, ist der Server im Wesentlichen eine Übersetzung von Endpunkten in Tool-Definitionen mit guten Beschreibungen. Eine erste Version sind Tage, keine Wochen.
Ist Ihre API nicht gut entworfen, erbt der Server jedes Problem. Endpunkte, die fünf aufeinanderfolgende Aufrufe für eine nützliche Sache verlangen, produzieren einen Agenten, der fünf Aufrufe macht und auf halbem Weg den Faden verliert. Das sollte man vorher wissen — MCP legt API-Designqualität ungewöhnlich schonungslos offen, denn der Konsument kann Ihre Doku nicht lesen und die unbequemen Stellen nicht umschiffen.
Die Fälle, in denen es sich klar lohnt: Ihre Kunden sind technisch, Ihre API ist das Produkt, oder Ihre Nutzer fragen bereits, ob Sie sich mit ihrem KI-Tooling integrieren. Der Fall, in dem nicht: ein internes System mit drei Nutzern und keinem Agenten in Sicht.
Wie die Verbindung tatsächlich läuft
Ein praktisches Detail entscheidet viel über Ihr Deployment: MCP-Server laufen in zwei Formen, und die passen zu verschiedenen Situationen.
Ein lokaler Server läuft als Prozess auf derselben Maschine wie der Client und kommuniziert über Standard-Ein- und -Ausgabe. So verbindet sich das meiste Desktop-KI-Tooling mit Dingen — der Server hat die Zugriffe des Nutzers, keine Netzwerk-Exponierung, keine separate Authentifizierung. Hervorragend für Entwicklerwerkzeuge und persönliche Automatisierung, nutzlos für einen Dienst, den andere konsumieren.
Ein Remote-Server läuft über HTTP — das wollen Sie, wenn Sie ein Produkt anbieten. Damit kehren alle gewöhnlichen Sorgen zurück: Authentifizierung, Rate-Limits, Mandantentrennung, Transportsicherheit — und dort sitzt der Grossteil des echten Engineerings. Das Protokoll sagt zur Authentifizierung fast nichts, absichtlich — Sie verwenden also Ihr bestehendes Schema, statt ein neues einzuführen.
Für eine Firma, die eine API anbietet, ist der Remote-Server die relevante Form — und die ehrliche Einordnung lautet: Sie liefern eine weitere öffentliche Angriffsfläche aus, mit allem, was dazugehört. Es ist kein Plugin.
Was man richtig machen muss
Beschreibungen sind die Schnittstelle. Ein Tool namens search, beschrieben als «durchsucht Dinge», wird zufällig aufgerufen. Eines mit «Durchsucht Kundenbestellungen nach E-Mail, Bestell-ID oder Zeitraum. Liefert bis zu 50 Treffer mit Status und Summe.» wird korrekt aufgerufen. Investieren Sie hier echte Zeit; es zählt mehr als der Code.
Tools auf ganze Jobs zuschneiden. Ein Tool, das eine nützliche Sache erledigt, schlägt drei, die verkettet werden müssen. Jeder zusätzliche Aufruf ist eine weitere Chance für das Modell, den Faden zu verlieren.
Fehler zurückgeben, mit denen ein Agent etwas anfangen kann. «Ungültige Anfrage» ist eine Sackgasse. «Das Datum muss JJJJ-MM-TT sein; Sie sendeten 12/03/2026» erlaubt einen erfolgreichen zweiten Versuch.
Davon ausgehen, dass der Aufrufer manipuliert sein kann. Ein Agent, der die E-Mail eines Kunden liest, kann von dieser E-Mail angewiesen werden, Ihr Lösch-Tool aufzurufen. Ihr Server ist eine Grenze: Erzwingen Sie Autorisierung bei jedem Aufruf, statt darauf zu vertrauen, dass am anderen Ende ein braver Agent sitzt. Das ist gewöhnliche API-Sicherheit — und sie zählt hier mehr, weil der Client genuin unberechenbar ist.
Antworten klein halten. Alles, was Sie zurückgeben, kostet Kontext. Ein Tool, das hundert Felder auskippt, wo sechs gebraucht wurden, macht den Agenten schlechter und den Aufruf teurer.
Beginnen Sie mit drei Tools für Ihren häufigsten Anwendungsfall, schreiben Sie die Beschreibungen sorgfältig, und testen Sie gegen einen echten Agenten. Ein Nachmittag, an dem Sie ihm beim Falschwählen zusehen, lehrt Sie mehr als jede Menge Design.
Drei Tools, sorgfältige Beschreibungen, ein echter Agent — mit diesem Nachmittag beginnen unsere Agent-Projekte. Wir machen ihn mit Ihnen.
