MCP vs. API: Was ein MCP-Server wirklich hinzufügt

Irgendwann im letzten Jahr ist „Brauchen wir einen MCP-Server?“ neben „Brauchen wir eine App?“ auf die Liste der Fragen gerückt, die in einem Briefing stehen, bevor irgendwer gesagt hat, wofür das Ding eigentlich da sein soll. Meistens wird sie gestellt, als wäre MCP eine neuere, bessere Art von API, auf die man umsteigt. Ist es nicht. Ein MCP-Server ist eine Übersetzungsschicht zwischen einer KI-Anwendung und einem System, das fast immer schon eine API hat, und in den meisten echten Projekten ruft er genau diese API bei jeder einzelnen Anfrage auf. Hier steht, wofür beides da ist, wo die Grenze verläuft, was der Bau eines Servers wirklich bedeutet und welchen Teil die Demos weglassen.

MCP und API im direkten Vergleich

Die MCP-Spalte folgt der im September 2026 gültigen Spezifikation, Revision 2026-07-28. Ressourcen und Prompts sind optional, und viele Server bieten nur Tools an.

Was MCP eigentlich ist

Das Model Context Protocol ist ein offener Standard, den Anthropic im November 2024 veröffentlicht hat, um KI-Anwendungen mit externen Systemen zu verbinden. Die eigene Dokumentation greift zum Vergleich mit „einem USB-C-Anschluss für KI-Anwendungen“: eine einzige Steckerform, damit jede KI-Anwendung, die ihn unterstützt, an jedes System andocken kann, das ihn anbietet, statt für jede Kombination ein eigenes Kabel zu brauchen.

Es gibt drei Rollen. Der Host ist die Anwendung, die ein Mensch tatsächlich benutzt: Claude, ChatGPT, ein Editor wie VS Code oder Cursor. Darin hält ein Client genau eine Verbindung zu genau einem Server. Der Server ist das Stück, das du bauen würdest: ein Programm, das dem Client sagt, was es kann, und es dann tut. Die beiden sprechen JSON-RPC 2.0, über Standardein- und -ausgabe, wenn der Server auf demselben Rechner läuft, oder über Streamable HTTP, wenn er woanders läuft.

Ein Server kann drei Arten von Dingen anbieten. Tools sind Aktionen, die das Modell auslösen kann: Bestellungen suchen, eine Rechnung erstellen, einen Termin buchen. Ressourcen sind Daten, die die Anwendung in das Gespräch holen kann, etwa eine Datei oder ein Datensatz. Prompts sind wiederverwendbare Vorlagen, die ein Mensch aus einem Menü auswählt. In der Gegenrichtung kann ein Server mitten in einer Aufgabe anhalten und mehr verlangen, am nützlichsten über Elicitation, also eine Rückfrage an die Person, die ihn benutzt.

Das Protokoll bewegt sich noch schnell, und vieles, was 2025 darüber geschrieben wurde, beschreibt heute eine ältere Version. Die aktuelle Revision vom 28. Juli 2026 hat den einleitenden Handshake und die Sessions auf Protokollebene komplett abgeschafft, sodass jede Anfrage ihre Version und ihre Fähigkeiten jetzt selbst mitbringt, ganz ähnlich wie ein gewöhnlicher API-Aufruf. Sie hat lang laufende Tasks in eine optionale Erweiterung verschoben und Sampling und Roots als veraltet markiert, also die Funktionen, mit denen sich ein Server das Modell des Hosts leihen oder fragen konnte, in welchen Ordnern er arbeiten darf.

Der Unterschied in einem Satz

Eine API sagt einem Menschen, der programmiert, was ein System kann; ein MCP-Server sagt es einem Modell, zur Laufzeit, in Worten, über die es nachdenken kann. Alles in der Tabelle oben folgt daraus. Eine API setzt voraus, dass jemand die Dokumentation gelesen, die Endpunkte ausgewählt, die Fehler behandelt und Code ausgeliefert hat, der sie jedes Mal gleich aufruft. Ein MCP-Server setzt voraus, dass das niemand getan hat: Das Modell entdeckt die Tools beim Verbinden, liest ihre Beschreibungen und entscheidet selbst, welches zu dem passt, was die Person gerade gefragt hat.

Deshalb zählen Tool-Beschreibungen viel mehr, als Endpunkt-Dokumentation je gezählt hat. Ein vage benannter Endpunkt kostet jemanden im Entwicklungsteam zehn Minuten. Ein vage beschriebenes Tool kostet dich jedes Gespräch, in dem das Modell das falsche wählt oder das richtige mit den falschen Argumenten, und keiner merkt es, weil die Antwort trotzdem selbstsicher klingt.

MCP-Server umhüllen APIs. Sie ersetzen sie nicht

Schau in fast jeden MCP-Server, und ganz unten steckt ein API-Aufruf. Der offizielle GitHub-Server ruft die GitHub-API auf. Wenn du einen Assistenten bittest, ein Issue anzulegen, läuft die Kette so: Das Modell wählt das Tool, der Client schickt eine JSON-RPC-Anfrage, der Server macht daraus eine ganz normale HTTPS-Anfrage an die API, die es seit Jahren gibt, und die Antwort nimmt denselben Weg zurück.

Wir arbeiten selbst so. Wir nutzen MCP-Server jeden Tag in unserer eigenen Arbeit, darunter Blender und Hugging Face, und jeder davon ist eine dünne Schicht über einer Schnittstelle, die schon da war: der Python-API von Blender, der Hugging-Face-Hub-API. Diese Schicht ist es, die ein Modell sie nutzen lässt, ohne dass jemand für jede Aufgabe neuen Verbindungscode schreibt.

Die eigentliche Frage lautet also nie „API oder MCP“. Wenn dein System keine API hat, brauchst du noch keinen MCP-Server. Du brauchst eine API, und der Server kommt danach. Hat es schon eine gute, ist der Server eine vergleichsweise kleine Schicht obendrauf. Die Wahl der API darunter ist eine eigene Entscheidung, und REST vs. GraphQL behandelt sie.

Warum ein Standard und nicht einfach Function Calling

Modelle konnten schon vor MCP Funktionen aufrufen. Jeder große Anbieter hat ein Tool-Calling, bei dem du mit der Anfrage eine Liste von Funktionen mitschickst und das Modell mit der antwortet, die es ausführen will. Der Unterschied ist, wem die Verdrahtung gehört. Beim reinen Function Calling definiert jede Anwendung ihre Tools im eigenen Code, für einen einzigen Modellanbieter. Bei MCP liegen die Tool-Definitionen im Server, und jeder kompatible Host kann sich damit verbinden.

Das macht aus einer Multiplikation, bei der jede KI-Anwendung für jedes System eine eigene Integration baut, eine Addition: Jede Anwendung implementiert einmal einen Client, jedes System einmal einen Server. Genau deshalb hat sich das Protokoll so schnell verbreitet. OpenAI hat es im März 2025 übernommen, Google hat im April angekündigt, dass Gemini es unterstützen wird, und Microsoft und GitHub sind im Mai seinem Lenkungsausschuss beigetreten. Im Dezember 2025 ist das Protokoll in die Agentic AI Foundation gewandert, ein neues Dach unter der Linux Foundation, mitgegründet von Anthropic, OpenAI und Block, mit Google, Microsoft, AWS und Cloudflare unter den Mitgliedern. Dieser Schritt wiegt schwerer, als er klingt: Er ist der Unterschied zwischen dem Feature eines einzelnen Anbieters und der Infrastruktur einer ganzen Branche.

Wann sich ein MCP-Server lohnt

In drei Situationen, und sie haben eines gemeinsam: Was dein System aufruft, ist ein KI-Modell, das jemand anderes ausgesucht hat. Erstens: Du verkaufst ein Produkt mit API, und deine Kundschaft arbeitet längst in KI-Assistenten. Ein Server lässt sie dein Produkt von dort aus nutzen, und immer mehr erwarten genau das. Zweitens: Dein Team will internen Systemen Fragen in normaler Sprache stellen (Bestellungen, Lagerbestand, Tickets), aus dem Assistenten, den es ohnehin nutzt, ohne dass du eine eigene Chat-Oberfläche baust. Drittens: Du willst, dass eine einzige Integration jede KI-Anwendung bedient statt eine pro Anbieter.

Und drei, in denen es das falsche Werkzeug ist. Ein fester Ablauf mit bekannten Schritten, etwa „wenn eine Bestellung eingeht, Rechnung erstellen und per E-Mail schicken“, verlangt deterministische Automatisierung, die die API direkt aufruft; ein Modell, das jeden Schritt entscheidet, bringt Kosten und eine neue Fehlerquelle, aber keinen Gewinn. Die Plattformen für diese Hälfte haben wir in Zapier vs. Make vs. n8n verglichen. Eine einzelne Integration zwischen zwei deiner eigenen Systeme verlangt einen schlichten API-Aufruf. Und alles, was Geld bewegt oder Daten löscht, verlangt einen Menschen in der Schleife, was MCP möglich macht, aber nicht erzwingt.

Was der Bau wirklich bedeutet

Die Protokollseite ist der leichte Teil. Es gibt offizielle SDKs für die meisten gängigen Sprachen, darunter TypeScript, Python, C#, Go, Java und Kotlin, und ein Server, der drei Endpunkte einer bestehenden API umhüllt, kommt mit ein paar hundert Zeilen aus. Wenn dir eine Demo reicht, ist das ein Tag Arbeit.

Die Produktionsarbeit liegt woanders, und damit auch der Aufwand. Zuerst müssen die Tools für ein Modell entworfen werden, nicht für einen Menschen, der programmiert: weniger, auf höherer Ebene, mit Beschreibungen für den Leser, der sie tatsächlich benutzt. Anthropics eigener Leitfaden nennt Tools, die „bloß bestehende Softwarefunktionen oder API-Endpunkte umhüllen“, einen häufigen Fehler, und das Beispiel dort ist ein einzelnes search_contacts-Tool statt eines list_contacts, bei dem sich das Modell durch alle Kontakte blättern muss. Dann die Autorisierung, die bei einem entfernten Server OAuth 2.1 bedeutet, Metadaten für geschützte Ressourcen, die Prüfung, dass jedes Token für deinen Server ausgestellt wurde, und niemals das Weiterreichen des Client-Tokens an die API dahinter, was die Spezifikation ausdrücklich verbietet. Das Protokollieren jedes Tool-Aufrufs, mit der Angabe, wer gefragt hat und was passiert ist. Berechtigungen und Rate-Limits, denn ein Modell ruft ein Tool vergnügt 400-mal auf, wenn die Aufgabe danach auszusehen scheint. Das ist der Teil eines Projekts für API & Integrationen, der die Zeit kostet.

Dazu kommen Kosten, die auf der Seite des Modells anfallen, nicht auf deiner. Jede Tool-Definition wird in den Kontext des Modells geladen. Das Engineering-Team von Anthropic hat ein Beispiel durchgerechnet, in dem Tool-Definitionen und Zwischenergebnisse, die durch das Modell liefen, auf 150.000 Tokens kamen, und den Verbrauch auf rund 2.000 gesenkt, indem es das Modell Code gegen die Server schreiben ließ. Jedes Tool, das du anbietest, kostet in jedem Gespräch, deshalb schlagen ein paar gute Tools ein Spiegelbild deiner kompletten API.

Sicherheit: der Teil, den die Demos überspringen

Ein MCP-Server gibt einem Modell Hände, und ein Modell nimmt Anweisungen von allem an, was es liest. Diese Kombination hat bereits ein ganzes Jahr echter Vorfälle geliefert. Im April 2025 zeigte Invariant Labs Tool Poisoning: Anweisungen, versteckt in der Beschreibung eines Tools, unsichtbar für die Nutzerin und befolgt vom Modell. Im Mai 2025 zeigte dasselbe Team, wie ein präpariertes Issue in einem öffentlichen GitHub-Repository einen Agenten mit dem offiziellen GitHub-Server dazu brachte, Daten aus privaten Repositories preiszugeben, und stellte klar, dass der Fehler nicht im Code des Servers lag, sondern in der Architektur. Im Juni 2025 nahm Asana seinen MCP-Server fast zwei Wochen vom Netz, nachdem ein Logikfehler Daten für andere Organisationen sichtbar gemacht hatte; das Unternehmen bezifferte die betroffene Kundschaft auf rund 1.000. Im Juli 2025 erlaubte eine Lücke in mcp-remote, einem weit verbreiteten Verbindungswerkzeug, Remote Code Execution auf dem Rechner aller, die es mit einem nicht vertrauenswürdigen Server verbanden. Im September 2025 schickte ein bösartiges npm-Paket, getarnt als E-Mail-Server, von jeder versendeten Nachricht heimlich eine Blindkopie an seinen Autor.

Simon Willison hat das Muster hinter den meisten dieser Fälle „lethal trifecta“ getauft, ein tödliches Trio: ein Agent mit Zugriff auf private Daten, der nicht vertrauenswürdigen Inhalten ausgesetzt ist und einen Weg hat, Daten nach außen zu schicken. Je zwei davon lassen sich beherrschen. Alle drei zusammen bedeuten, dass jeder, der Text vor das Modell bringen kann, in einer E-Mail, einem Support-Ticket, einer Produktbewertung oder einer Webseite, versuchen kann, es deine Daten irgendwohin schicken zu lassen. Das BSI hat den GitHub-Fall in seiner Handreichung zu Angriffen auf Sprachmodelle vom Januar 2026 als Fallstudie verwendet und kommt zu dem Schluss, dass selbst bei Umsetzung aller relevanten Gegenmaßnahmen Restrisiken verbleiben können. Gib einem MCP-Server die engsten Berechtigungen, mit denen er seine Aufgabe erfüllt, denn der feindseligste Text, den er je liest, bekommt dieselben Rechte wie du.

In der Praxis heißt das: standardmäßig nur lesende Tools und schreibende Tools nur hinter einer ausdrücklichen Bestätigung, ein Server pro Vertrauensgrenze statt eines Servers, der alles darf, fixierte und geprüfte Abhängigkeiten statt dessen, was die Paketregistry heute ausliefert, und niemals ein Tool, das beliebiges SQL oder beliebige Shell-Befehle gegen die Produktion ausführt. Wie KI-Agenten das Hacking verändert haben zeigt die Seite der Angreifer, und die Sicherheit von KI-generiertem Code den Code, mit dem solche Server immer öfter geschrieben werden.

Wie du entscheidest

Fang bei der API an. Wenn du keine saubere, dokumentierte, authentifizierte API hast, ist genau das das Projekt, und es zahlt sich aus, ob ein KI-Modell sie je anfasst oder nicht. Wenn du eine hast, frag dich, wer dein System über ein Modell aufrufen wird und was damit passieren soll: lesen oder etwas ändern. Nur lesen ergibt einen kleinen, sicheren ersten Server. Schreibzugriff ist ein echtes Projekt mit einer Sicherheitsprüfung dazu.

Dann bau den kleinsten Server, der die häufigste Frage beantwortet, stell ihn echten Nutzerinnen und Nutzern hin und lies die Logs. Die Tool-Aufrufe zeigen dir schneller als jedes Designdokument, was das Modell wirklich braucht. Die Modell-Hälfte dieser Arbeit deckt unser Bereich KI & Automatisierung ab; die deterministische Hälfte beginnt meistens mit Workflow-Automatisierung.

Quellen

Geprüft im September 2026. Das Protokoll wird oft überarbeitet, daher verweisen die Links zur Spezifikation auf die aktuelle Revision 2026-07-28; die Vorfälle sind auf den Zeitpunkt ihrer Veröffentlichung datiert. Die Einschätzung, wann sich ein Server lohnt, ist unsere.

• Model Context Protocol — What is MCP? ↗

  Die Definition von MCP als offener Standard zur Verbindung von KI-Anwendungen mit externen Systemen und der Vergleich mit „einem USB-C-Anschluss für KI-Anwendungen“.

• Model Context Protocol — Specification 2026-07-28, key changes ↗

  Die zustandslose Revision: kein initialize-Handshake und keine Sessions auf Protokollebene mehr, Tasks in eine Erweiterung verschoben, Roots, Sampling, Logging und Dynamic Client Registration als veraltet markiert.

• Model Context Protocol — Tools ↗

  Tools als vom Modell gesteuert, entdeckt über tools/list mit Name, Beschreibung und JSON-Schema für die Eingabe, und Tool-Fehler, die an das Modell zurückgehen, damit es sich korrigieren kann.

• Model Context Protocol — Authorization ↗

  OAuth 2.1 für HTTP-Transporte, Metadaten für geschützte Ressourcen (RFC 9728), Tokens, die an den empfangenden Server gebunden sind (RFC 8707), und die Regel, dass Server keine anderen Tokens annehmen oder weiterreichen.

• Model Context Protocol — Security best practices ↗

  Das Confused-Deputy-Problem bei Proxy-Servern, Token-Passthrough als Anti-Pattern und Zustands-Handles, die niemals als Authentifizierung gelten dürfen.

• Anthropic — Introducing the Model Context Protocol ↗

  Die Ankündigung vom 25. November 2024, die MCP als neuen Standard beschreibt, um KI-Assistenten mit den Systemen zu verbinden, in denen die Daten liegen.

• Linux Foundation — Formation of the Agentic AI Foundation ↗

  Dezember 2025: MCP, goose und AGENTS.md als Gründungsprojekte, Anthropic, Block und OpenAI als Mitgründer, AWS, Bloomberg, Cloudflare, Google und Microsoft unter den Mitgliedern.

• TechCrunch — OpenAI adopts rival Anthropic’s standard for connecting AI models to data ↗

  März 2025, der Beginn der Unterstützung außerhalb von Anthropic, zuerst im Agents SDK von OpenAI.

• Anthropic Engineering — Writing effective tools for agents ↗

  Tools, die bloß bestehende API-Endpunkte umhüllen, als häufiger Fehler benannt, und das Beispiel search_contacts statt list_contacts.

• Anthropic Engineering — Code execution with MCP ↗

  Ein durchgerechnetes Beispiel, kein Benchmark: Tokenverbrauch von 150.000 auf 2.000 gesenkt, eine Ersparnis von 98,7 %, indem das Modell die Server aus Code heraus aufruft.

• Invariant Labs — Tool poisoning attacks ↗

  April 2025: Anweisungen, versteckt in Tool-Beschreibungen, unsichtbar für die Nutzer und sichtbar für das Modell.

• Invariant Labs — GitHub MCP exploited ↗

  Mai 2025: Ein bösartiges öffentliches Issue bringt einen Agenten dazu, Daten aus privaten Repositories preiszugeben, von den Forschenden als Architekturproblem beschrieben, nicht als Bug im Server.

• BleepingComputer — Asana warns MCP AI feature exposed customer data to other orgs ↗

  Juni 2025: ein Logikfehler, kein Angriff, mit rund 1.000 betroffenen Kunden und einem Server, der für die Behebung vom Netz ging.

• JFrog — Critical RCE vulnerability in mcp-remote (CVE-2025-6514) ↗

  Juli 2025: CVSS 9,6, Remote Code Execution auf dem Rechner des Clients beim Verbinden mit einem nicht vertrauenswürdigen Server, behoben in Version 0.1.16.

• The Hacker News — First malicious MCP server found ↗

  September 2025: das npm-Paket postmark-mcp, das ab Version 1.0.16 jede versendete E-Mail als Blindkopie an eine fremde Adresse schickte.

• Simon Willison — The lethal trifecta for AI agents ↗

  Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit, nach außen zu kommunizieren, und warum gerade die Kombination aller drei gefährlich ist.

• BSI — Evasion-Angriffe auf LLMs: Gegenmaßnahmen in der Praxis ↗

  Januar 2026: Das Bundesamt für Sicherheit in der Informationstechnik nutzt den GitHub-MCP-Fall als Fallstudie und hält fest, dass selbst bei Umsetzung aller relevanten Gegenmaßnahmen Restrisiken verbleiben können.