Diese Frage kommt in jedem zweiten Gespräch, und sie kommt von den Leuten, die ihr Produkt am besten kennen. Meistens vom CTO. Sie ist berechtigt, und die ehrliche Antwort fängt mit einem Zugeständnis an.

Zuerst das Zugeständnis

Es gibt nichts, was MCP technisch kann und eine gut gebaute API nicht. Kein Merkmal, keine Fähigkeit, keinen Trick. Alles, was das Protokoll macht, kannst du selbst bauen, mit HTTP, JSON und OAuth. Wer dir etwas anderes erzählt, verkauft dir gerade etwas.

Der Unterschied liegt nicht darin, was möglich ist. Er liegt darin, wer was wissen muss, damit es funktioniert.

Vier Stellen, an denen sich das zeigt.

1. Der Schlüssel und der Ausweis

Ein API Key ist ein Schlüssel. Er gehört einem System, nicht einer Person. Er passt, bis ihn jemand sperrt, und er weiss nicht, wer ihn gerade in der Hand hält. Was der Schlüssel darf, darf jeder, der ihn hat.

OAuth ist ein Ausweis. Ausgestellt auf einen Menschen, mit Ablaufdatum, mit begrenztem Umfang, jederzeit einziehbar. Dein System sieht, wer handelt.

Und jetzt das Zugeständnis: Deine API kann OAuth genauso. Viele APIs machen das seit Jahren.

Was MCP hinzufügt, ist nicht der Ausweis, sondern der Weg dorthin. Ein fremder Client klopft ohne Token an deinen Server. Er bekommt eine Abfuhr, in der steht, wo das Ausweisbüro ist und welche Berechtigung er für diese eine Aufgabe braucht. Danach geht er selbst hin. Niemand verschickt einen Key per Mail, niemand trägt irgendwo Zugangsdaten ein, und niemand aus deinem Support erklärt einem Kunden, wo er sein Token findet.

Dazu kommt etwas, das im Alltag mehr wert ist, als es klingt: Berechtigungen lassen sich mitten in der Arbeit nachziehen. Der Agent darf lesen. Sobald er etwas schreiben will, sagt dein Server, welche Berechtigung dafür fehlt, und der Mensch erteilt genau diese. Nicht alles am Anfang, auf Verdacht.

Der Vollständigkeit halber: MCP zwingt dich zu nichts davon. Die Spezifikation nennt Autorisierung ausdrücklich optional, und ein lokal laufender Server darf seine Zugangsdaten weiterhin aus der Umgebung lesen. Standardisiert ist der Weg, nicht die Pflicht.

2. Breit gebaut oder zugeschnitten

Deine API ist bewusst breit, und das ist ihre Stärke, nicht ihr Mangel. Sie ist für Entwickler gebaut, die damit Dinge lösen sollen, an die beim Entwurf niemand gedacht hat. Vollständigkeit ist das Merkmal. Wer eine API auf neun Endpunkte zusammenstreicht, hat keine gute API gebaut, sondern eine schlechte.

Die Agentenschnittstelle hat die umgekehrte Anforderung, aus einem sehr konkreten Grund: Die Liste der verfügbaren Aufgaben liegt dem Modell vor, bevor irgendjemand weiss, worum es überhaupt geht. Sie wird bei jeder einzelnen Anfrage mitgelesen. Eine Schnittstellenbeschreibung dagegen wird nachgeschlagen, wenn die Frage bereits existiert.

Deshalb kostet Breite in den beiden Welten etwas völlig Verschiedenes. In der API kostet sie im Ruhezustand nichts. In der Aufgabenliste kostet sie bei jedem Aufruf, und sie kostet Orientierung genau in dem Moment, in dem entschieden wird.

Das ist ausdrücklich kein Argument über die Grenzen des Modells. Ich lasse täglich ein Modell eine öffentliche API bedienen, mit nichts als der Schnittstellenbeschreibung und einem Zugang, und es arbeitet sich sauber durch. Der Unterschied liegt nicht im Können. Er liegt darin, was im Augenblick der Entscheidung vor dem Modell liegt.

Also wird anders geschnitten. Nicht «Objekt anlegen, Feld setzen, Feld setzen, Status ändern, veröffentlichen», sondern «Befragung starten». So konkret wie möglich, entlang der Aufgaben, die deine Kunden wirklich haben. Neun davon statt zweihundert Operationen.

Dazu kommt ein Nebeneffekt, der im Verkauf schwerer wiegt als die Orientierung. Beim Schnitt nach Aufgaben liegt die Reihenfolge in deinem Code. Bei zweihundert generischen Endpunkten setzt der Agent sie selbst zusammen, jeder Kunde ein wenig anders, und die Regeln, die zwischen den Aufrufen gelten und nirgends geschrieben stehen, kennt er nicht. Das Ergebnis kann technisch einwandfrei und fachlich falsch sein. Der Kunde sieht dann nicht seinen Agenten, sondern dein Produkt.

Und wieder das Zugeständnis: Deine API kann diesen Schnitt auch. Ein Endpunkt namens «Befragung starten» ist kein Protokollmerkmal, sondern eine Entwurfsentscheidung.

Nur muss sie es nicht. Breit funktioniert für sie, denn davor sitzt ein Entwickler, der die Dokumentation liest und fünf Schritte hintereinander macht. Die Agentenschnittstelle funktioniert breit nicht. MCP macht den Schnitt nicht möglich. Es macht ihn nötig.

Was du dabei in Kauf nimmst: Du pflegst ab jetzt zwei Oberflächen auf demselben Kern. Die breite für Entwickler, die schmale für Agenten. Kein Umbau deiner API, sondern eine zweite Sicht darauf, aber es ist Arbeit, die vorher nicht da war.

Und die eigentliche Frage steckt genau dort. Welche neun Aufgaben es sind, ist keine Protokollfrage, sondern eine Produktfrage. Sie ist der teure Teil.

3. Die dritte Partei

Hier trennen sich die beiden Welten wirklich.

Ein API Aufruf kennt zwei Beteiligte: das aufrufende Programm und deinen Server. Der Mensch kommt im Vertrag nicht vor. HTTP hat keinen Begriff dafür, dass hinter dem Aufrufer jemand sitzt. Dein Server kann dem Programm antworten, mehr nicht: ja, nein, Fehler.

Der MCP Vertrag kennt drei Beteiligte. Der dritte ist der Mensch.

In der aktuellen Fassung vom 28. Juli 2026 läuft das so: Dein Server kann eine Aufgabe nicht zu Ende bringen, ohne etwas zu wissen, das nur ein Mensch entscheiden kann. Also liefert er statt eines Ergebnisses eine Zwischenantwort, mit der Frage und mit einem Formular, das er für genau diesen Fall erzeugt hat. Der Client zeigt es der Person. Die Person antwortet. Der Client ruft dieselbe Aufgabe noch einmal auf, diesmal mit der Antwort im Gepäck.

Damit dich niemand damit erwischt: Das ist kein offener Draht. Es ist ein zweiter Anruf. Seit dieser Fassung hat MCP überhaupt keine Sitzungen mehr, jede Anfrage steht für sich allein. Für den Menschen davor fühlt es sich trotzdem wie ein Gespräch an, und darauf kommt es an.

Zwei Dinge sind darin festgelegt, die eine API so nicht kennt.

Erstens entsteht die Frage zur Laufzeit, aus den Daten. Sie ist keine Auswahl aus einer Liste, die jemand vor zwei Jahren beim Entwurf vorgesehen hat.

Zweitens gibt es einen Modus, in dem dein Server die Person auf eine eigene Seite schickt, und weder der Client noch das Modell sehen, was dort passiert. Für Zugangsdaten schreibt die Spezifikation das sogar vor: Passwörter, Schlüssel und Zahlungsdaten dürfen nie im Formular abgefragt werden. So bekommst du sensible Dinge am Modell vorbei, vertraglich zugesichert statt selbst gebastelt.

Und der Mensch hat drei Antworten statt zwei: ja, nein, und «ich entscheide das jetzt nicht». Ein REST Aufruf hat keine Vokabel dafür, dass jemand den Dialog weggeklickt hat.

4. Der Fall, an dem eine API nicht mehr reicht

Ein konstruiertes Beispiel, aber eines aus meiner Welt.

Jemand sagt seinem Assistenten: «Schick die Zufriedenheitsbefragung an alle Kunden, die im letzten Quartal einen Supportfall hatten.»

Der Aufruf ist vollständig. Kein Pflichtfeld fehlt, nichts ist mehrdeutig, jede API würde jetzt senden.

Dann fällt deinem Produkt etwas auf, das der Aufrufer nicht wissen konnte: Ein Teil dieser Gruppe hat einen Fall, der eskaliert und noch offen ist.

Das ist kein technisches Problem, sondern eine Abwägung.

Schickst du an alle, misst du die Verstimmung der offenen Fälle mit und verzerrst genau die Kennzahl, um die es ging. Nimmst du sie heraus, fehlt dir das Segment, dessen Meinung am meisten zählt. Oder du schickst ihnen später eine andere, kürzere Fassung, sobald der Fall geschlossen ist.

Niemand hat «hat offene Eskalation» als Parameter von «Befragung senden» vorgesehen. Niemand konnte das, denn der Konflikt entsteht erst aus den Daten von heute.

Der Einwand, der jetzt kommt: Der Agent könnte doch vorher nachsehen. Nein. Dafür müsste er wissen, dass offene Eskalationen einen Zufriedenheitswert verzerren. Dieses Wissen steckt in deinem Produkt, nicht im Modell.

Darum geht es: Das Fachwissen sitzt in deinem System, das Gespräch sitzt in einem fremden Client. Bis hierhin gab es keinen festgelegten Weg, das eine ins andere zu bringen.

Und ja, deine API kann auch einen Fehlercode mit drei Optionen zurückgeben. Danach erklärst du ChatGPT, Copilot, Claude und dem selbstgebauten Agenten deines grössten Kunden, was dieser Fehlercode bedeutet. Einmal pro Client. Für immer.

Die Konvention, und was sie kostet

Der eigentliche Grund für MCP ist kein technischer.

Im Dezember 2025 wurde das Protokoll an die Agentic AI Foundation übergeben, einen Fonds unter der Linux Foundation. Mitgegründet von Anthropic, Block und OpenAI, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Direkte Unterstützung gibt es unter anderem in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und Visual Studio Code.

Die Branche hat sich geeinigt. Nicht auf den besten Entwurf, sondern auf einen. Mehr ist eine Konvention nie, und weniger auch nicht.

Was sie dir bringt: Dein Kunde verbindet dein Produkt mit seinem Assistenten, ohne dass du für diesen Assistenten irgendetwas gebaut hättest. Das ist der ganze Nutzen, und er ist gross.

Was sie kostet, ebenso ehrlich:

  • Sie bewegt sich. Zwischen Juni 2025 und Juli 2026 kamen zwei neue Fassungen, beide mit Brüchen. Der Handshake ist weg, die Sitzungen sind weg, drei Funktionen aus dem Kern sind abgekündigt. Meistens nimmt dir das dein SDK als Abhängigkeitsupdate ab. Teuer wird es dort, wo du um die entfernten Teile herum etwas Eigenes gebaut hast. Und der Takt kommt von aussen, nicht aus deiner Roadmap.
  • Sie ist kein Burggraben. Was du damit begründest, dass es alle so machen, hat genau die Lebensdauer dieser Aussage.
  • Die dünne Hülle bringt nichts. Eine MCP Schicht, die deine öffentliche API nur weiterreicht, fügt nichts hinzu ausser einem zweiten Endpunkt, den du pflegen musst. Der Wert liegt dort, wo die Berechtigungen und die internen Methoden liegen, also mitten in deinem Produkt.
  • Es entsteht eine neue Fläche. Die Beschreibungen deiner Werkzeuge sind Text, den ein Modell liest und ernst nimmt. Wer dort schreibt, schreibt in fremde Anweisungen hinein. Das ist ein Sicherheitsthema, und es ist neu.

Was du wirklich entscheidest

Die Frage lautet nicht MCP oder API. Beides funktioniert, und beides hat seinen Platz: die breite Schnittstelle für Entwickler, der schmale Schnitt für Agenten. Darunter liegen drei andere Fragen:

  • Welche Aufgaben deines Produkts darf ein fremder Agent auslösen?
  • Mit wessen Rechten, und wer kann sie wieder entziehen?
  • An welchen Stellen muss dein Produkt zurückfragen, bevor es etwas tut, das sich nicht rückgängig machen lässt?

Beantworte diese drei, und das Format ist eine Frage von Tagen. Beantworte sie falsch, und kein Protokoll rettet dich.

Das Protokoll ist die Verpackung. Der Schnitt ist das Produkt.