Ist MCP tot?

(quandri.io)

1 Punkte von GN⁺ 5 시간 전 | 2 Kommentare | Auf WhatsApp teilen

MCP verbindet LLMs mit externen Tools, aber in Entwicklungs-Workflows zeigen sich Kontextkosten, betriebliche Stabilität und Überschneidungen mit CLI/API als große Belastung
Bei Messungen von Quandri beanspruchten 77 Tool-Definitionen für Linear, Notion, Slack und Postgres etwa 21.077 Tokens und damit 10,5 % des 200K-Kontexts von Claude
Das Abrufen von Linear-Issues verbraucht mit MCP etwa 12.957 Tokens, weil 42 Tool-Definitionen immer mitgeladen werden, und damit deutlich mehr als der CLI-Ansatz mit rund 200 Tokens
MCP bringt separate Serverprozesse sowie Authentifizierung, Initialisierung, Konflikte und zusätzliche Roundtrip-Latenz mit sich, während sich CLI/API im Terminal leicht reproduzieren, debuggen und kombinieren lassen
Quandri verpackte bestehende CLIs als Skills und gewann so rund 21K Tokens zurück; MCP wird nur dann verwendet, wenn keine CLI vorhanden ist oder teamweite Zugriffskontrolle nötig ist

Die zentralen Kosten, die MCP offenlegt

MCP (Model Context Protocol) verbindet LLMs mit externen Tools wie GitHub, Linear, Notion und Slack, aber in realen Entwicklungs-Workflows werden Kontextverbrauch, betriebliche Stabilität und Überschneidungen mit bestehenden CLI/API-Schnittstellen zu den Hauptproblemen
Seit der Einführung Ende 2024 wurde es als „USB-C des AI-Ökosystems“ bezeichnet, doch für Entwickler, die es täglich nutzen, treten andere Kosten zuerst zutage
In Claude Code wurde nach diesen Messungen Tool Search with Deferred Loading eingeführt, das MCP-Tool-Schemata nur bei Bedarf lädt und den Kontextverbrauch um mehr als 85 % reduziert
In der aktuellen Version von Claude Code ist das Problem der Kontextaufblähung weitgehend entschärft, doch Performance-, Debugging- und Architekturprobleme bleiben bestehen

Hoher Verbrauch des Kontextfensters

Das Kontextfenster ist der Arbeitsbereich, den ein LLM für eine Aufgabe nutzt. Wenn ein MCP-Server verbunden wird, belegen oft schon die Tool-Definitionen selbst einen großen Teil davon und nicht die eigentliche Arbeitsaufgabe
In der Quandri-Umgebung wurden die tatsächlichen Tool-Definitionen der verbundenen MCP-Server extrahiert und gemessen. Wenn alle vier Server verbunden sind, werden allein durch die Tool-Definitionen 10,5 % des Kontextfensters verbraucht
Größe der Tool-Definitionen:
- Linear: 42 Tools, ca. 51.229 Zeichen, ca. 12.807 Tokens
- Notion: 14 Tools, ca. 16.156 Zeichen, ca. 4.039 Tokens
- Slack: 12 Tools, ca. 15.168 Zeichen, ca. 3.792 Tokens
- Postgres: 9 Tools, ca. 1.755 Zeichen, ca. 438 Tokens
- Insgesamt: 77 Tools, ca. 84.308 Zeichen, ca. 21.077 Tokens
Kontextverbrauch je Modell:
- Im 200K-Kontext von Claude nehmen die Tool-Definitionen 10,5 % ein
- Im 128K-Kontext von GPT-4o nehmen die Tool-Definitionen 16,5 % ein
Allein Linear lädt immer 42 Tool-Definitionen und belegt damit mehr als 12.800 Tokens, selbst wenn tatsächlich nur get_issue und save_issue verwendet werden
Beispiele für große Tool-Definitionen:
- linear/save_issue: 2.479 Zeichen, ca. 619 Tokens
- slack/search_public: 1.614 Zeichen, ca. 403 Tokens
- linear/list_issues: 1.588 Zeichen, ca. 397 Tokens
- notion/fetch: 1.379 Zeichen, ca. 344 Tokens
- slack/send_message: 1.248 Zeichen, ca. 312 Tokens

Belastung bei Stabilität und Performance im Betrieb

MCP muss einen separaten Prozess starten und am Laufen halten, wodurch Initialisierungsfehler und wiederholte Authentifizierungsprobleme auftreten können
Jeder Tool-Aufruf erfordert einen Roundtrip zu einem externen Server, was die Antwortgeschwindigkeit der AI verlangsamt
Wenn ein MCP-Serverprozess abstürzt, können Tools mitten in einer Sitzung verschwinden
Welche Berechtigungen ein Tool tatsächlich besitzt, ist oft unklar, wodurch die Sichtbarkeit von Rechten gering ist
Im Jira-MCP-Benchmark aus MCP is dead. Long live the CLI war MCP pro Aufruf dreimal langsamer als ein direkter REST-API-Aufruf; der erste Aufruf inklusive Initialisierung war 9,4-mal langsamer
Dieser Performance-Unterschied ist nicht auf Jira beschränkt, sondern ergibt sich aus der Struktur, in der zwischen LLM und der eigentlichen API mit dem MCP-Server eine zusätzliche Prozessschicht eingefügt wird
Derselbe Overhead gilt auch für die Linear-, Notion- und Slack-Server im Quandri-Stack

Überschneidung mit bestehender CLI/API

CLI/API können von Menschen und LLMs mit denselben Befehlen genutzt werden, während MCP nur innerhalb des LLM-Dialogs existiert
CLI/API lassen sich frei mit Pipes, jq und grep kombinieren, während MCP an das vom Server zurückgegebene Format gebunden ist
CLI/API lassen sich im Terminal sofort reproduzieren und debuggen, während MCP nur im Gesprächskontext reproduzierbar ist
LLMs haben die Nutzung von CLI/API bereits über man pages und StackOverflow gelernt, während MCP separate Tool-Definitionen benötigt
CLI/API sind meist ohnehin installiert, während MCP zusätzliche Serverkonfiguration, Authentifizierung und Prozessverwaltung erfordert

Token-Kosten beim Abrufen eines Linear-Issues

Beim Abrufen desselben Linear-Issues verbraucht der MCP-Ansatz etwa 65-mal mehr Tokens als der CLI-Ansatz
Der CLI-Ansatz verbraucht etwa 200 Tokens:
- curl-Befehl im Prompt: ca. 50 Tokens
- Antwort: ca. 150 Tokens
Der MCP-Ansatz verbraucht etwa 12.957 Tokens:
- 42 immer geladene Linear-Tool-Definitionen: ca. 12.807 Tokens
- Tool-Aufruf und Antwort: ca. 150 Tokens
Das CLI-Beispiel ruft die Linear-GraphQL-API direkt auf:

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

Alternative: CLI-first-Strategie und Skills

Ein Ansatz, der in der Reihenfolge CLI → API → Dokumentation bereitstellt, ist leichter und direkter
LLMs haben die Nutzung von CLI bereits über man pages und StackOverflow gelernt, daher müssen separate Tool-Definitionen nicht ständig mitgeführt werden
Wenn bestehende CLIs direkt verwendet werden, wird kein Kontext für Tool-Definitionen verschwendet, und weil Mensch und AI dieselbe Schnittstelle nutzen, wird das Debugging einfacher
Über Pipelines lässt sich der Ansatz frei mit anderen Befehlen kombinieren
Wenn MCP „alle Menüs vorab auf dem Tisch ausbreitet“, dann sind Skills eher so, als würde man „den Bibliothekar nur nach dem benötigten Buch fragen“
MCP lädt beim Verbindungsaufbau alle Tool-Definitionen und belegt damit dauerhaft Kontext, während Skills nur bei Bedarf geladen werden und nur während der Nutzung Kontext verbrauchen
Je mehr Server hinzukommen, desto stärker steigt der Kontextdruck bei MCP, während Skills nicht dauerhaft proportional zur Anzahl der Skills Kontext belegen
Der Kern besteht darin, Anweisungen zur CLI-Nutzung in Skills zu hinterlegen; in Kombination mit einer CLI-first-Strategie ist das am effizientesten
Das Beispiel für einen Linear-Skill enthält nur die API-URL, die Authentifizierungsmethode, den curl-Befehl zum Abrufen von Issues, die GraphQL-Suchmethode und den Hinweis, JSON mit jq zu parsen:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Bei diesem Ansatz lädt das LLM den obigen Inhalt nur dann in den Kontext, wenn der entsprechende Skill aufgerufen wird
Statt ständig 42 Linear-Tool-Definitionen mitzuführen, werden nur die tatsächlich benötigten CLI-Befehle geladen

Fälle, in denen MCP weiterhin sinnvoll ist

Wenn ein Service keine CLI hat, kann MCP die einzige Verbindungsform sein
Für Nicht-Entwickler, die kein Terminal verwenden, kann MCP leichter zugänglich sein
Für Echtzeitkommunikation in beide Richtungen, die über einfache Request-Response-Muster hinausgeht, kann MCP geeignet sein

Kriterien für die Wahl beim Datenbankzugriff

Datenbankzugriff läuft letztlich auf das Ausführen von Queries hinaus, und LLMs kennen SQL- und MongoDB-Queries bereits gut
Wenn DB-Informationen und CLI-Nutzung in einem Skill hinterlegt und das Schema bereitgestellt werden, kann ein LLM auch ohne MCP Queries schreiben
Das Beispiel für einen Postgres-Skill enthält nur Host, Tabellenschema und die Nutzung der psql-CLI:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

Für Datenbanken hat MCP auch Vorteile:
- Query-Sicherheit: Ein MCP-Server kann einen Read-only-Modus erzwingen und riskante Queries auf Serverebene blockieren
- Schutz von Zugangsdaten: Beim CLI-Ansatz kann der Connection-String im Prompt sichtbar werden, während ein MCP-Server die Credentials intern verwaltet
Für lokale Entwicklung oder persönliche Datenbanken sind Skills + CLI leichtgewichtig, schnell und leichter von Fehlern zu erholen
Für produktive Datenbanken oder gemeinsam genutzte Team-Umgebungen ist MCP eher geeignet, weil Schutzmechanismen wie Query-Validierung und Zugriffskontrolle auf Serverebene wichtig sind
In den meisten Entwickler-Workflows ist MCP jedoch leicht überdimensioniert

Wie Quandri es verwendet

Quandri nutzt je nach Service Bash + CLI, Skills und MCP gemeinsam
Für täglich verwendete Tools wie gh, psql und aws wird Bash + CLI verwendet:
- keine Kontextkosten
- hohe Flexibilität
- direkt im Terminal debuggbar
Für wiederkehrende, mehrstufige Workflows wie Commit-Erstellung und PR-Review werden Skills verwendet:
- werden nur beim Aufruf geladen
Für Services ohne starke CLI wie Slack, Linear und Notion wird MCP verwendet
Auch bei Zugriff auf produktive Datenbanken, wo teamweite Authentifizierung oder Berechtigungsabgrenzung wichtig sind, wird MCP verwendet
Wenn bereits eine CLI vorhanden ist und lokale Authentifizierung möglich ist, ist dieser Weg meist der leichtgewichtigste
Wenn ein Service keine CLI hat oder im ganzen Team einheitliche Authentifizierung nötig ist, hat MCP einen echten Mehrwert

Fazit und Messmethode

Wichtiger als alles miteinander zu verbinden, ist es, gut anzuleiten
Bei Quandri wurden MCP-Server durch Skills ersetzt, die bestehende CLIs umhüllen, wodurch rund 21K Tokens an Kontext zurückgewonnen wurden
Im täglichen Workflow verschwanden Initialisierungsfehler, und das Debugging blieb im Terminal
Effizienter ist ein Ansatz, bei dem nur die nötigen Tools zum nötigen Zeitpunkt zusammen mit CLI-Anweisungen geladen werden
MCP kann sich künftig weiterentwickeln und solche Probleme lösen, aber nach heutigem Stand sind Skills die bessere Wahl
Messmethode:
- In der Claude-Code-Umgebung wurden die JSON-Schemata aller tatsächlich geladenen Tools der MCP-Server extrahiert
- Gemessen wurde anhand von Tool-Namen, Beschreibungen und Parametern
- Für die Tokenschätzung wurde die Heuristik von ungefähr 1 Token pro 4 Zeichen verwendet
- Die Gesamtschätzung pro Server wurde aus dem Durchschnitt der Stichproben-Tools extrapoliert

Möchten Sie weitere kuratierte Tech-Themen erhalten? Folgen Sie dem Telegram-Kanal. @GeekNewsDE

2 Kommentare

aer0700 3 시간 전

Ich denke, man sollte einfach die Technik wählen, die zur eigenen Situation passt. Von tot zu sprechen, erscheint mir schwierig, denn dafür wird es bereits viel zu häufig genutzt.

GN⁺ 5 시간 전

Hacker-News-Kommentare

Ich leite bei OpenAI das Team, das sich um den ChatGPT App Store, Codex-Plugins und MCP insgesamt kümmert. Was Beiträge mit der Aussage „MCP ist tot“ übersehen, ist, dass es praktisch nicht wichtig ist, ob MCP als Transportprotokoll verwendet wird.
MCP ist nicht tot, weil fast jedes Unternehmen auf der Welt MCP-Server baut, und wir wissen das, weil wir direkt mit ihnen in Kontakt stehen.
Viele dieser Unternehmen haben keine CLI und nicht einmal eine externe API, bauen aber trotzdem einen MCP-Server.
Intern könnte man alle MCP-Server in eine CLI umwandeln, den Code-Modus verwenden oder Tool Discovery implementieren, aber das sind nur Implementierungsdetails. Der Kernpunkt ist, dass KI-Agenten auf Services zugreifen können, auf die sie ursprünglich keinen Zugriff hatten.
Ob MCP als Kommunikationsschicht, mit der Modelle direkt sprechen, tot ist, mag unklar sein, aber dass MCP als Protokoll tot sei, stimmt überhaupt nicht.
Wegen der Computer-/Browser-Nutzungsfunktionen der Codex-App ist dieses Argument schwächer als früher, und wenn man es noch nicht ausprobiert hat: Es ist wirklich erstaunlich.
- Ich halte es für sehr wahrscheinlich, dass MCP sterben wird.
  Der Hauptgrund ist, dass man unabhängig davon, ob die tatsächliche Implementierung eine API, das Web oder eine CLI ist, noch eine zusätzliche Schicht und zusätzliche Menschen darüberlegt, bei denen die Synchronisierung auseinanderlaufen kann.
  KI sollte nicht ein anderes Protokoll oder einen anderen Befehlssatz verwenden als das, worauf Menschen zugreifen, was sie verstehen und nutzen.
  Im Moment wollen Unternehmen MCP-Server bereitstellen, weil es im Trend liegt, aber in der Realität lässt man Claude einen MCP-Server über einer bestehenden API bauen und weist ihn gelegentlich erneut an, ihn an die öffentliche Dokumentation anzupassen.
  Die API-Dokumentation ist bereits öffentlich, und auch Claude Code hat den MCP-Server nur anhand der öffentlichen Dokumentation im Internet gebaut, daher fühlt sich MCP wie ein temporärer Workaround für die aktuellen Modellgrenzen an.
- MCP ist letztlich eher ein Markenname für eine „API, die von großen Sprachmodellen genutzt werden kann“.
  Dadurch bauen selbst Unternehmen, die vorher nicht besonders technikorientiert waren, APIs, damit ihre Tools im Agenten-Zeitalter nicht veraltet wirken.
  Das Ziel selbst unterstütze ich, aber ob ich dafür dieses Protokoll wählen würde, ist eine andere Frage, und so oder so ist es zu einem Protokoll geworden, von dem die Leute gehört haben und das sie tatsächlich verwenden.
- Die Aussage „Fast jedes Unternehmen auf der Welt baut MCP-Server“ klingt selbst wie eine Echo-Kammer.
- MCP verbraucht weiterhin wertvolles Kontextfenster, während es in Wirklichkeit ein Problem löst, das nicht existiert.
  Die Behauptung, dass Agenten ohne MCP nicht auf Services zugreifen könnten, ist bestenfalls missverständlich; wie im Artikel gesagt, ist der Zugriff auch allein über Kommandozeilen-Tools und deren Ein-/Ausgaben möglich.
  Auch aus rein technischer Sicht ist MCP in Bezug auf Komponierbarkeit schwächer als Kommandozeilen-Tools, und wer Komponierbarkeit nicht wichtig nimmt, wird am Ende den Preis dafür zahlen.
  Offen gesagt gibt es hier einen Investitionsbias, und die Tatsache, dass man MCP an unzählige Unternehmen verkauft, widerlegt diesen Bias nicht.
  Schon Microsoft zeigt, dass es kaum einen Zusammenhang damit gibt, wie nützlich etwas ist oder wie tief die Technik vergraben wird; manche würden sogar das Gegenteil behaupten.
  Ich vermute, dass OpenAI MCP derzeit auch stark aus organisatorischen Gründen vorantreibt, was intern womöglich schwer zu erkennen ist.
- Dass dort MCP gebaut wird, wo es keine CLI gibt, klingt ziemlich beunruhigend.
  Es ist etwas anderes, bestehende CLI-Funktionen für eine bessere Agenten-Integration zu duplizieren, als alle an eine einzige Schnittstelle zu binden, an die Spezifikation, die man später womöglich für weniger gut hält.
  Dann muss man später MCP-Schulden abtragen, und am Ende könnte es billiger gewesen sein, es gar nicht erst zu tun.
Ich frage mich, ob dieser Artikel von einer KI geschrieben wurde.
MCP ist im Wesentlichen eher so etwas wie JSON-RPC, das einige spezielle Felder enthalten muss.
Man kann JSON-RPC kritisch sehen, aber eine Service-Discovery-Schicht, mit der große Sprachmodelle sich integrieren können, ist nötig.
Das muss an vielen Stellen funktionieren können — auf Websites, in Desktop-Anwendungen, in Backend-Services — und eine CLI ist nur einer der Berührungspunkte mit solchen Systemen.
Wodurch man MCP auch ersetzen würde: Selbst wenn man Kommunikationsprotokoll oder Tool-Discovery-Felder anders festlegt, wird es wahrscheinlich auf eine ähnliche Form hinauslaufen.
- Jedes Mal, wenn ich etwas über MCP lese, wirkt es, als würden das gesamte Internet oder ganz HN kollektiv durchdrehen.
  Es heißt, APIs seien besser als MCP, aber MCP ist letztlich nur eine API mit ein wenig zusätzlicher Anleitung, damit KI ihre Verwendung entdecken kann.
  Manche sagen auch, man solle eine CLI verwenden, aber ich weiß nicht genau, was das bedeuten soll.
  Dass große Sprachmodelle gängige CLI-Tools wie ffmpeg gut nutzen, liegt daran, dass dieses Wissen in ihren Gewichten verankert ist.
  Wenn man ein neues CLI-Tool baut, muss man der KI trotzdem noch beibringen, wie sie es benutzt; wenn man diesen „Lehr“-Teil vom Server bereitstellen will, ist das MCP, und wenn man ihn lokal in statischer Form haben will, ist es ein Skill.
  Ich verstehe nicht, warum es über ein so simples Konzept so viele Debatten gibt.
- Das Problem ist, dass MCP vergleichsweise dauerhaft Kontext belegt und nicht zusammen mit einem sauberen System für Installation/Entfernung und Discovery kommt.
  Skills müssten vollständig auf MCP basieren, nur bei Bedarf geladen werden und sowohl für Menschen als auch für KI leicht verwaltbar und auffindbar sein, damit das wirklich gut funktioniert.
  Betrachtet man den tatsächlichen Anwendungsbereich, war der ursprüngliche Scope zu eng, und wenn man darauf noch etwas aufsetzt, könnte es vielleicht noch wiederbelebt werden.
Bei der Behauptung „Problem 1: Es frisst das Kontextfenster auf“ ist mir nicht klar, worin der Unterschied dazu besteht, nacheinander linearcli --help, notioncli --help und slackcli --help auszuführen
Im Gegenteil: Bei MCP kann die Ausführungsumgebung nur die Titel der einzelnen Tools in den Kontext legen, und die vollständige Dokumentation bei Bedarf je nach MCP-Server und Tool nachladen
Um mit einer CLI denselben Effekt zu erzielen, müsste jede CLI einen Befehl wie --short-descr anbieten
Auch „Problem 2: geringe operative Zuverlässigkeit“ überzeugt nicht: Wenn ein Tool eine REST API nutzt, ist das Protokoll ähnlich, also gibt es keinen Grund, warum MCP langsamer sein sollte
Falls es langsamer ist, liegt das wahrscheinlich an der Implementierung, etwa weil MCP zusätzlich über die API gelegt wurde und auf einem ausgelagerten Server in einem entfernten Rechenzentrum läuft
Dass die meisten MCP-Server miserabel sein könnten, mag sein, aber das ist kein Protokoll-, sondern ein Branchenproblem
„Problem 3: Es überschneidet sich mit bestehender CLI/API“ stimmt, wenn bereits ein CLI-Tool existiert, und ein SQL-MCP-Server oder ein curl-MCP wirkt wie Tokenverschwendung
Aber in den meisten Organisationen gibt es keine CLI, und selbst wenn doch, dann meist nur APIs, die für Programme und nicht für große Sprachmodelle entworfen wurden
Zu sagen „Liefert erst CLI → API → Dokumentation“ klingt für mich so, als würde man verlangen, dass Unternehmen statt einer langsamen und verschwenderischen Website zuerst einen nativen Desktop-Client und einen nativen Mobile-Client bereitstellen sollen
- Ich habe mich nicht tief in das Thema eingearbeitet, aber soweit ich weiß, wird MCP – abgesehen von den neuesten Claude-Code-Releases – vorab in den Kontext geladen
  Wenn man es nicht häufig braucht, muss man es ausschalten und bei Bedarf wieder einschalten
  Wenn man Nutzungsbeispiele in die Skill-Datei packt, kann man den ersten --help-Aufruf eventuell reduzieren, und bei einer CLI scheint es auch einfach, einen Sub-Agenten mit separatem Kontext zu starten und nur das Ergebnis zurückzubekommen
Im Artikel steht zwar kein Datum, aber es heißt, Lazy Tool Loading sei ein jüngstes Update nach dem Schreiben des Artikels gewesen
Allerdings wurde Lazy Tool Loading im November 2025 hinzugefügt: https://www.anthropic.com/engineering/advanced-tool-use
Diese Zahlen sind also mindestens sieben Monate alt, und ich weiß nicht, warum das gerade jetzt gepostet wurde
- Schon dass das überhaupt noch diskutiert wird, wirkt seltsam
  Wegen Lazy Tool Loading, großem Kontext und Prompt Caching ist 2026 völlig anders als 2025
  Auch die Debatte, dass CLI Token spare, bricht zusammen, wenn der erste Schritt ohnehin das Ausführen von --help ist
  Wenn man sich die Aufrufweise und Parameter nicht merken kann, bleibt das Problem bestehen, dass sie am Ende doch im Kontext stehen müssen
- Außerdem wirkt der Text noch älter und deutet an, GPT-4o sei das Neueste
- Lazy Tool Loading ist kein Teil von MCP
  Es ist ein Claude-API-spezifischer Parameter, den die meisten anderen APIs für große Sprachmodelle nicht unterstützen
- Der Artikel ist vom 29. Mai 2026, und zu behaupten, dieses Update sei eine „jüngste“ Änderung nach dem Artikel gewesen, ist eine Lüge, damit sie selbst besser dastehen
Ich glaube, es gab einen sehr guten Beitrag dazu, dass MCP auf Organisationsebene gut passt, wenn man nichttechnischen Mitarbeitenden, die interne Agenten-Tools nutzen, vereinheitlichten und sicheren Zugriff auf interne Utility-APIs geben muss
Der Workflow wird als Skill codifiziert und zwischen Instanzen geteilt, während MCP alles übernimmt, was kontextbewussten API-Zugriff braucht
- Meinst du diesen Artikel? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Falls ja, würde mich interessieren, worin der Vorteil von MCP gegenüber direktem API-Zugriff durch Agenten besteht
- Ich frage mich, ob das an die Stelle eines Berechtigungssystems zum Schutz der API tritt
  Für die API müsste es ohnehin irgendeine Form von Berechtigungsmechanismus geben
- Genau das
  Dass Unternehmen wie Runlayer so schnell wachsen, liegt genau daran, und ohne zentrale Control Plane wird MCP zum Minenfeld
Zusätzlich zu den bereits genannten Punkten ist Remote-MCP servergesteuert, sodass Produzenten neue Funktionen hinzufügen können, ohne Skills und CLIs aller Clients aktualisieren zu müssen
Außerdem ist Remote-MCP sicherer, weil es auf dem lokalen System keine Berechtigung zur tatsächlichen Codeausführung benötigt
Skills bündeln Skripte oft mit npx/uvx, und das ist faktisch so riskant wie curl npm.com | bash
Ich habe einmal einen Skill gebaut, der Teams an ein internes Verwaltungssystem angebunden hat, und am Ende haben wir ihn als MCP registriert
MCP exponiert nur Dokumentations-Grep und API-Aufrufe und ist für sich genommen völlig nutzlos, aber der Hauptgrund für diesen Weg war die Bereitstellung
Nichttechnische Teams wollen eine UI, in der sie eine URL hinzufügen und dann alles funktioniert und OAuth sie anleitet, und MCP macht das in Claude oder ChatGPT möglich
Auch die Art, wie MCP-Aufrufe in der Chat-UI sichtbar sind, ist besser und für die Nutzenden klarer
Statt mit MCP-Servern zu hantieren und eine CLI für alle Plattformen auszurollen, könnte man die API vielleicht einfach über SSH bereitstellen
SSH ist ein perfektes Protokoll für große Sprachmodelle
Coding-Agenten können es ohnehin schon nutzen, und ssh api@example.com list-users reicht völlig aus
Bei 90 % der Nutzer dürfte SSH bereits installiert sein, und sowohl Eingabe als auch Ausgabe sind Text – also ideal für große Sprachmodelle
Es deckt Public-Key-Authentifizierung, Streaming-Ausgabe, interaktive Ein-/Ausgabe und auf Wunsch sogar Dateiübertragung per scp/rsync ab
Wenn die Nutzer ihr Konto mit Github oder GitLab verknüpft haben, könnte man sogar ihre SSH-Schlüssel einsammeln und die Authentifizierung vorab einrichten, sodass sie sich einfach verbinden und sofort drin sind
- Man muss das nur auf die Größenordnung einer ganzen Organisation hochskalieren
Die Restaurant-Analogie ist schlecht
So nach dem Motto: „Zehn Speisekarten liegen auf dem Tisch ausgebreitet, sodass kein Platz mehr für das Essen ist, und bei jeder Bestellung muss die Speisekarte wieder hervorgeholt werden“ – dabei sind wiederholte Bestellungen außer in Tapas-Restaurants nicht besonders üblich
Man kann das Essen auch auf die Speisekarte stellen, und normalerweise räumt man die Speisekarte nach der Bestellung weg und macht so den Tisch – also den Kontext – frei
Wenn man etwas mit einer Analogie erklären will, sollte man sich mehr Mühe geben, sie tatsächlich relevant zu machen