MCP ist leise tot. Corsair zeigt, was es ersetzt.
Ich hatte dreiundvierzig Werkzeuge an einen einzigen Agenten angeschlossen und sah zu, wie er in Echtzeit den Verstand verlor.
Die Aufgabe war dumm einfach. „Rufen Sie die letzten zehn E-Mails aus meinem Gmail ab und fassen Sie alles zusammen, was mit dem Vorschlag zusammenhängt, den ich am Dienstag gesendet habe.“ Ein zweistufiger Job. E-Mail lesen. Zusammenfassen. Das ist es. Stattdessen rief der Agent ein Slack-Suchtool auf. Dann ein Kalendertool, das ich für ein anderes Projekt angeschlossen hatte. Dann wurde versucht, gmail_get_messages aufzurufen – nur dass das nicht der Funktionsname war. Das eigentliche Tool war read_gmail_inbox. Der Agent hatte einen plausibel klingenden API-Aufruf aus einem Schema halluziniert, an das er sich anhand von 38.000 Tokens vorab erstellter Tooldefinitionen halb erinnert hatte.
Ich habe den Lauf abgebrochen, das Eingabeprotokoll geöffnet und gezählt. Bevor meine Eingabeaufforderung überhaupt das Modell erreicht hatte, hatte MCP über 40.000 Token von Toolschemata in das Kontextfenster eingefügt. Vierzigtausend Token. Um eine Frage zu zehn E-Mails zu beantworten. Der Agent hatte nie eine Chance.
Das war der Moment, in dem ich aufhörte, MCP zu verteidigen, und begann, nach dem zu suchen, was als nächstes kommt. Ich werde durchgehen, was ich gefunden habe – einschließlich eines kleinen Open-Source-Projekts namens Denn „MCP ist tot“ ist kein Hype. Das sagt die Mathematik aus, wenn man das Protokoll über die Spielzeugdemos hinaus vorantreibt.
Was MCP tun sollte
Anthropic veröffentlichte das Model Context Protocol Ende 2024 mit einem klaren, ehrgeizigen Pitch. LLMs sind Gehirne ohne Hände und Beine. Sie können hervorragend über Code, Sprache und Strategie nachdenken, aber sie können ohne externe Installation keinen Tweet posten, Ihren Posteingang lesen oder eine Tabelle aktualisieren. MCP sollte genau das sein – standardisiert, herstellerneutral und universell.
Der Mechaniker war unkompliziert. Sie legen ein Werkzeug frei. Das Tool kündigt ein JSON-Schema an, das seinen Namen, seine Parameter und seine Funktion beschreibt. Der MCP-Client fügt zu Beginn der Konversation das Schema jedes verfügbaren Tools in das Kontextfenster des Modells ein. Das Modell wählt das richtige Tool aus, generiert einen strukturierten Aufruf und die Laufzeit führt ihn aus. Werkzeug hinzufügen. Holen Sie sich die Fähigkeit. Wiederholen.
Ich habe mich komplett darauf eingelassen. Letztes Jahr habe ich über die drei MCPs, die Claude zu meinem Operations-Hub gemacht haben geschrieben – die Vernetzung von Canva, Zapier und Stripe hat meine Arbeitsweise etwa sechs Monate lang verändert. Mit drei oder vier Werkzeugen fühlt sich MCP magisch an. Das Protokoll verschwindet. Man fragt in einfachem Englisch nach Dingen und sie passieren.
Aber drei oder vier Werkzeuge sind die Spielzeugversion. In dem Moment, in dem Sie skalieren – in dem Moment, in dem Sie versuchen, den tatsächlichen Stack, den ein Berufstätiger verwendet, zusammenzubauen –, bricht die Architektur auf drei spezifische Arten auf.
Das Kontextfenster-Aufblähungsproblem
Hier ist die Nummer, die für mich die Romanze beendete.
Laut einem Benchmark von Scalekit aus dem Jahr 2025 kostete derselbe Vorgang, der 1.365 Token über eine CLI erforderte, 44.026 Token über MCP. Das ist ungefähr das 32-fache des Token-Overheads, und fast alles davon war Schema-Injection – 43 Tooldefinitionen, die in den Kontext gepackt wurden, bevor der Agent auch nur ein einziges Zeichen der eigentlichen Frage des Benutzers gelesen hatte. Jede andere seriöse Analyse, die ich seitdem gelesen habe, landet in derselben Nachbarschaft. Das Entwicklungsteam von CodeRabbit hat gemessen, dass einzelne MCP-Server im Vorfeld mehr als 55.000 Schema-Tokens verbraucht haben. Untersuchungen von Cyclr ergaben, dass Schemata bei mehr als 50 Tools 5–7 % eines 200 KB großen Kontextfensters beanspruchen können, bevor die Konversation beginnt.
Lesen Sie diese Zahlen sorgfältig durch. Fünf bis sieben Prozent Ihres Kontexts sind verschwunden, bevor jemand etwas eingegeben hat.
Das Problem ist architektonischer Natur, nicht der Implementierungsebene. MCP wurde unter der Annahme entwickelt, dass das Modell jedes Werkzeug sehen muss, um jedes Werkzeug verwenden zu können. Diese Annahme war vernünftig, als Agenten über vier oder fünf Tools verfügten. Es ist katastrophal, wenn sie vierzig haben. Und vierzig ist nicht die Obergrenze – das ist ungefähr das, was ein einzelner arbeitender Entwickler zwischen GitHub, Slack, Linear, Sentry, seiner Datenbank, seinem E-Mail-Konto, seinem Kalender und seinem CMS ansammelt.
Ich habe zugesehen, wie meine eigenen Setups über 60 Werkzeuge hinausschossen, ohne es zu versuchen. Jedes sieht „frei“ aus, wenn Sie es hinzufügen. Jeder besteuert jede einzelne zukünftige Anfrage, unabhängig davon, ob Sie sie nutzen oder nicht.
Wenn die Halluzinationen beginnen
Hier ist der Teil, den die meisten Artikel verschweigen. Die Tokenkosten sind das langweilige Problem. Das interessante Problem besteht darin, was mit der Argumentation des Modells passiert, wenn seine Aufmerksamkeit auf Dutzende von Werkzeugschemata verteilt werden muss.
Es gibt ein Muster, das ich mittlerweile sowohl in meinen eigenen Protokollen als auch in den veröffentlichten Forschungsergebnissen wiederholt gesehen habe. Sobald die Kontextauslastung etwa 70 % überschreitet, bricht die Genauigkeit der Werkzeugauswahl des Modells zusammen. Es beginnt, Parameter zwischen ähnlichen Tools zusammenzuführen. Es ruft das richtige Tool mit Argumenten aus dem Schema eines anderen Tools auf. Es erfindet Werkzeuge, die es nicht gibt, die aber so klingen, wie sie sollten. Und – dieses hier ist wirklich beunruhigend – es tut dies alles mit voller Zuversicht. Die halluzinierten Anrufe sehen genauso aus wie die echten.
Die Benchmarks im Scalekit-Stil passen auch zu akademischen Arbeiten. Das RAG-MCP-Papier von arXiv (2505.03275) führte einen Stresstest durch, bei dem ein LLM mit einem wachsenden Pool von MCP-Werkzeugbeschreibungen gefüttert wurde, und beobachtete, wie die Auswahlgenauigkeit drastisch sank. Mit dem vollständigen Schema-Dump-Ansatz – wie MCP heute funktioniert – haben sie eine Werkzeugauswahlgenauigkeit von 13,62 % gemessen. Bei der abrufbasierten Auswahl erreichte das gleiche Modell bei den gleichen Suchanfragen 43,13 %. Mehr als das Dreifache der Genauigkeit mit weniger als der Hälfte der Prompt-Tokens.
Das ist kein Tuning-Problem. Das ist ein „Der gesamte Ansatz ist falsch“-Problem.
Ich gebe Ihnen das konkreteste Beispiel aus meinen eigenen Tests. Ich hatte zwei Tools angeschlossen: send_email (über Gmail MCP) und send_message (über Slack MCP). Gleiche Verbstruktur. Verschiedene Plattformen. Verschiedene Parameterformen. Bei etwa jedem siebten Durchlauf generierte der Agent einen Aufruf an send_email mit den Slack-Parametern channel und text. Die Laufzeit würde es ablehnen. Der Agent entschuldigte sich, versuchte es erneut und hatte manchmal Erfolg und manchmal scheiterte er auf andere Weise. Bei jedem erneuten Versuch wurden Token verbrannt. Jeder Fehlermodus war einzigartig. Das Debuggen fühlte sich an, als würde man Geister jagen.
Als ich auf zwölf Werkzeuge reduzierte, sank die Ausfallrate auf nahezu Null. Zwölf Tools – für einen Agenten, der einen Job erledigt. Das ist die praktische Decke, die Ihnen MCP in der Produktion bietet.
Die Schemafragmentierungssteuer
Während die Spezifikation von MCP technisch standardisiert ist, ist die Realität der anbieterübergreifenden Ausführung im Jahr 2026 chaotischer, als das Marketing vermuten lässt.
Ich habe mittlerweile MCP-Server von mindestens acht verschiedenen Anbietern verbunden und kann Ihnen mit absoluter Sicherheit sagen, dass hinter dem „JSON-Schema“ ein Meer an Inkonsistenzen steckt. Einige Server geben Fehler als strukturierte Objekte zurück. Einige geben Fehler als Zeichenfolgen zurück, die in erfolgreiche Antworten eingefügt werden. Einige Server paginieren. Einige tun dies nicht und kürzen stillschweigend. Einige Server berücksichtigen die optionale Feldunterscheidung /required. Manche behandeln alles nach Bedarf und brechen ab, wenn man etwas weglässt. Die Authentifizierung reicht von sauberem OAuth bis hin zu „Dieses Token in eine Konfigurationsdatei einfügen und beten“.
Jede dieser Inkonsistenzen zwingt entweder das Modell oder den Entwickler dazu, defensive Logik zu schreiben. Multiplizieren Sie das mit der Anzahl der MCP-Server, die Sie betreiben, und aus dem „Unified Protocol“-Versprechen wird „JSON-Schemasuppe mit Adaptercode in der Mitte“.
Das tiefere Problem ist, dass MCP den Transport standardisiert hat, nicht aber die Semantik. Zwei Server können beide gültige MCP sein und sich nicht ähnlich verhalten. Das ist in Ordnung, wenn Sie ein oder zwei haben. Es ist eine Integrationssteuer, wenn man zwanzig ist.
Mehr Builder als Benutzer
Hier ist das Signal, über das niemand in den MCP-Marketingmaterialien sprechen möchte. Schauen Sie sich die Register an. Pulse MCP. Anthropics Connectors-Verzeichnis. Schmiedekunst. Glama. Mittlerweile gibt es Tausende von MCP-Servern. Die meisten von ihnen haben eine Handvoll GitHub-Stars und fast keine tatsächlichen Benutzer.
Die Community ist voll von Leuten, die MCP-Server bauen. Es gibt überraschend wenig Leute, die sie in großem Maßstab in der Produktion betreiben. Der Grund ist kein Geheimnis – es sind die drei Probleme, die ich gerade durchgemacht habe. Wenn Sie zum ersten Mal versuchen, fünfzehn dieser Dinge in einen Agenten zu integrieren, stoßen Sie an die Wand. Sie ziehen sich stillschweigend auf drei oder vier Tools zurück, oder Sie geben MCP vollständig auf und kehren zu direkten API-Aufrufen zurück, oder Sie beginnen, aggressiven Kontextverwaltungscode zu schreiben, um das zu komprimieren, was MCP einfügt.
Über genau dieses Muster habe ich in meinem Artikel über wie der Kontextmodus mein Claude-Code-Speicherproblem behoben hat geschrieben. Der Kontextmodus ist eine clevere Lösung für das Symptom – er entfernt die Ausgaben des MCP-Tools aus dem Kontext, nachdem sie verwendet wurden. Es behebt jedoch nicht das Upstream-Problem, dass jedes Schema beim Start eingefügt wird. Es verhindert lediglich, dass die Blutung den Patienten tötet.
Wenn das Workaround-Ökosystem größer wird als das Protokoll selbst, gerät das Protokoll in Schwierigkeiten.
Der mentale Modellwechsel: Vom Bibliotheksausweis zur Enzyklopädie
Hier ist der Rahmen, der bei mir endlich Klick gemacht hat. MCP behandelt Werkzeuge wie Bücher, die Sie mit sich herumtragen. Jedes Mal, wenn Sie ein Gespräch beginnen, laden Sie alle Bücher, die Sie möglicherweise benötigen, in Ihren Rucksack und denken dann, während Sie unter ihrem Gewicht erdrückt werden. Das Modell muss für alle Fälle ständig alle berücksichtigen.
Es gibt offensichtlich einen besseren Weg. Tragen Sie die Bücher nicht. Tragen Sie einen Index. Wenn Sie Informationen benötigen, schauen Sie nach, welches Buch diese enthält, holen Sie sich nur dieses Buch und lesen Sie.
Dies ist das Enzyklopädiemodell. Das Modell weiß, welche Bücher existieren – ihre Titel, eine einzeilige Beschreibung, die grobe Domäne – und ruft das vollständige Schema nur dann ab, wenn eine Abfrage es tatsächlich erfordert. Dies ist genau die Architektur, die RAG (Retrieval-Augmented Generation) vor einigen Jahren eingeführt hat, um Fragen und Antworten zu dokumentieren. Wir haben es einfach nicht auf die Werkzeugauswahl angewendet, weil das ursprüngliche MCP-Design den Maßstab nicht vorwegnahm.
Wenden Sie RAG auf Werkzeuge statt auf Dokumente an und die Mathematik kehrt sich um. Anstatt dass jede Konversation mit 40.000 Schema-Tokens beginnt, beginnt sie mit vielleicht 200 Tool-*Index-Tokens. Wenn der Benutzer nach etwas fragt, ruft eine Vektorsuche die zwei oder drei relevanten Werkzeugschemata ab, diese werden in den Kontext eingefügt und das Modell wählt eines aus. Die Halluzinationsraten sinken, weil das Modell nicht in ähnlich klingenden Optionen untergeht. Die Token-Kosten sinken, weil Sie für das bezahlen, was Sie nutzen, und nicht für das, was Sie möglicherweise nutzen. Die Anzahl der Werkzeuge ist praktisch unbegrenzt.
Karpathy weist schon seit einiger Zeit auf verwandte Ideen hin – ich habe einige seiner Überlegungen zur RAG-Architektur behandelt, als ich über den Aufbau einer persönlichen RAG-Wissensdatenbank in Obsidian schrieb. Werkzeuge sind nur eine weitere Art wiedergewinnbarer Artefakte. Wir sollten sie so behandeln.
Geben Sie Corsair ein
Corsair ist ein Open-Source-Projekt auf GitHub (github.com/corsairdev/corsair), das genau dieses Muster implementiert. Ich werde noch nicht so tun, als wäre es ein ausgefeiltes Produkt – das ist es nicht. Das Repo ist jung, die Dokumentation ist dünn und die Community ist klein. Aber die Architektur ist die ehrlichste Antwort, die ich je auf die Fragen gesehen habe, die MCP nicht beantworten kann.
So funktioniert es auf mechanischer Ebene.
Sie installieren Corsair als Schicht zwischen Ihrem Agenten und Ihren Tools. Es wird mit einem Katalog von Plugin-Definitionen für gängige Dienste ausgeliefert – Slack, Gmail, GitHub, Google Kalender und weitere werden hinzugefügt. Die Metadaten jedes Plugins befinden sich in einem Vektorindex. Wenn Ihr Agent eine Anfrage erhält, führt Corsair zunächst eine semantische Suche im Plugin-Katalog durch, ruft nur die Tool-Schemata des relevanten Plugins ab und stellt diese dem Modell zur Verfügung. Alles andere bleibt aus dem Kontext gerissen.
Für den Agenten sieht Corsair wie eine winzige Anzahl von Meta-Tools aus – den Katalog durchsuchen, ein Plugin abrufen, einen Aufruf ausführen. Für Sie als Entwickler entspricht das Offenlegen von zwanzig Integrationen ungefähr einer Codezeile. Die Komplexität befindet sich in der Laufzeit von Corsair, wo sie hingehört.
Das Credential-Modell ist der Teil, den ich am meisten geschätzt habe. Corsair speichert die Authentifizierung lokal in einer On-File-Datenbank. Kein obligatorisches Cloud-Relay. Kein Dashboard eines Drittanbieters zur Verwaltung Ihrer OAuth-Tokens. Wenn Sie Ihren persönlichen Gmail und den GitHub Ihres Kunden mit demselben Agenten verbinden möchten, bleiben die Geheimnisse auf Ihrem Computer. Für jeden, der Agenten entwickelt hat, die sensible Systeme berühren, ist dies wichtiger als jede Feature-Spezifikationszeile.
Der Unterschied in der Entwicklererfahrung
Lassen Sie mich den Kontrast dazu konkretisieren, wie sich eine typische Verkabelungsarbeit bei jedem Ansatz anfühlt.
Unter MCP ist das Hinzufügen eines Dienstes eine mehrstufige Zeremonie. Finden Sie den richtigen MCP-Server. Lesen Sie die README-Datei. Konfigurieren Sie es in Ihrem Client (Claude Desktop, Cursor, benutzerdefinierte Laufzeit – sie unterscheiden sich alle geringfügig). Authentifizieren. Starten Sie Ihren Client neu. Prüfen. Beachten Sie, dass ein Parameter etwas anders benannt ist als in den Dokumenten angegeben. Debuggen. Stellen Sie fest, dass das Antwortformat des Servers nicht dem Standard entspricht. Schreiben Sie defensives Parsen. Starten Sie noch einmal neu. Tun Sie dies nun für den nächsten Service. Und das nächste.
Unter dem Abrufmuster im Corsair-Stil ähnelt das Hinzufügen eines Dienstes eher „Plugin registrieren, Anmeldeinformationen speichern, fertig“. Der Agent muss nicht neu konfiguriert werden. Das Kontextfenster wächst nicht. Nichts anderes im System muss davon erfahren.
Ich möchte hier präzise sein, weil ich wirklich versuche, nicht zu viel zu verkaufen. Insbesondere Corsair ist früh. Der Plugin-Katalog ist klein. Wenn Sie heute versuchen, es für eine Nische zu nutzen, werden Sie auf Ecken und Kanten stoßen. Aber das Muster – RAG-gesteuerter Tool-Abruf – ist es, dem sich alle ernsthaften Agenten-Infrastrukturprojekte, die ich mir angesehen habe, annähern. Anthropic selbst hat kürzlich Forschungsergebnisse zu Lazy Schema Loading und Dynamic Tool Gating veröffentlicht. Das arXiv-Papier „Tool Attention Is All You Need“ (2604.21816) führt das gleiche architektonische Argument aus einem anderen Blickwinkel an. Die Richtung ist vorgegeben, auch wenn sich die führende Umsetzung noch nicht vollständig herauskristallisiert hat.
Wo MCP immer noch Sinn macht
Ich möchte fair sein, denn ich denke, dass viele „X ist tot“-Beiträge ihre Sache überbewerten und an Glaubwürdigkeit verlieren. MCP ist nicht nutzlos. Für die Größenordnung, die die meisten von uns anstreben, ist es einfach schlecht geeignet.
MCP ist wirklich gut, wenn Sie über einen kleinen, festen, kuratierten Satz von Tools verfügen – sagen wir drei bis sieben –, auf den jedes Gespräch Zugriff haben soll. Das Schema-Upfront-Modell ist in diesem Maßstab in Ordnung. Die Latenz ist gering. Die Aufmerksamkeit des Modells kann sich entfalten, ohne unterbrochen zu werden. Die Standardisierungsvorteile des Protokolls überwiegen seinen Mehraufwand. Wenn Sie einen fokussierten Agenten erstellen, der eine Aufgabe erfüllt – einen Code-Reviewer mit drei Tools, einen Schreibassistenten mit vier – ist MCP in Ordnung. Es ist möglicherweise die richtige Antwort.
MCP macht auch als Backend Sinn. Sie können sich Abrufsysteme wie Corsair vorstellen, die unter der Haube MCP für den eigentlichen Tool-Aufruf sprechen, während die darüber liegende Erkennungsschicht nach Abrufprinzipien arbeitet. Das Protokoll wird zur Infrastruktur und nicht zum benutzerorientierten Modell. Das ist wahrscheinlich der Punkt, an dem das alles auf lange Sicht landet.
Wofür MCP nicht gut ist, ist die eigentliche Aufgabe, die die ehrgeizigsten Agenten erledigen müssen – über Dutzende von Diensten hinweg koordinieren, dynamisch festlegen, welche Tools für welche Aufgabe relevant sind, und unterhalb der Kontextnutzungsschwelle bleiben, bei der die Argumentation zusammenbricht. Für diese Arbeitslast ist das Schema-Injektionsmodell strukturell falsch und kann durch keine noch so große Kontextkomprimierung gerettet werden.
Was ich jetzt mache
Ich habe meine eigene Agenteninfrastruktur in zwei Tracks aufgeteilt. Für eng begrenzte Einzweck-Agenten – meinen Code-Review-Bot, meinen Screenshot-zu-CSS-Konverter, meinen E-Mail-Triage-Agenten – bleibe ich bei MCP. Jeweils drei bis fünf Werkzeuge. Kein Abruf erforderlich. Das Protokoll funktioniert.
Für meinen Allzweck-Betriebsagenten – derjenige, der E-Mail, Kalender, GitHub, mein CMS, meine Analysen, mein CRM und ein Dutzend andere Systeme bedienen muss – bin ich auf eine abrufbasierte Architektur umgestiegen. Heute im Corsair-Stil, in sechs Monaten möglicherweise etwas Ausgereifteres. Allein der Token-Gesetzentwurf rechtfertigte die Migration. Der starke Rückgang der halluzinierten Werkzeugrufe rechtfertigte dies doppelt.
Das mentale Modell, das ich jetzt auf jeden neuen Agenten anwende, lautet: Wie viele Werkzeuge werden benötigt? Wenn die Antwort „fünf oder weniger, jemals“ lautet, ist MCP in Ordnung. Wenn die Antwort „Ich weiß es wirklich nicht und wahrscheinlich mehr als zehn“ lautet, greife ich nach einer Recherche. Der Übergangspunkt liegt meiner Erfahrung nach bei etwa acht Werkzeugen, und er ist nicht gerade elegant – die Leistung nimmt schnell ab, sobald man ihn überschreitet.
Dieser einzige Entscheidungspunkt hat mir Stunden beim Debuggen halluzinierter Anrufe und Argumentationszusammenbrüche erspart. Ich wünschte, jemand hätte es mir vor einem Jahr gegeben.
Häufig gestellte Fragen
Ist MCP tatsächlich tot oder hat es nur große Probleme?
MCP ist für kleine, fokussierte Agenten mit drei bis sieben Tools nicht tot – dort funktioniert es gut. Für Allzweckagenten, die Zugriff auf Dutzende von Diensten benötigen, ist es funktionell tot, da die Schemainjektion zu einer Aufblähung des Kontexts und Halluzinationen bei der Toolauswahl führt, die durch abrufbasierte Ansätze sauber gelöst werden können. Die meisten Produktionsteams hybridisieren stillschweigend.
Was ist Corsair und ist es produktionsbereit?
Corsair ist eine Open-Source-Integrationsschicht für AI-Agenten (github.com/corsairdev/corsair), die RAG verwendet, um nur relevante Toolschemata pro Abfrage dynamisch abzurufen, anstatt sie alle im Voraus einzufügen. Es ist noch früh – kleiner Plugin-Katalog, sich weiterentwickelnde Dokumente – aber das Architekturmuster, das es darstellt, ist das, worauf sich die ernsthafte Agenten-Infrastruktur konzentriert.
Warum werden Agenten durch das Hinzufügen weiterer MCP-Tools schlechter?
Jedes MCP-Tool fügt zu Beginn der Konversation 550–1.400 Schematoken in den Kontext ein. Bei den letzten 50 Tools verbraucht dies 5–7 % eines 200 KB großen Kontextfensters, bevor die Frage des Benutzers überhaupt eintrifft. Sobald die Kontextauslastung etwa 70 % überschreitet, fragmentiert die Aufmerksamkeit des Modells auf ähnlich aussehende Tools, die Halluzinationsrate steigt und die Genauigkeit der Toolauswahl bricht zusammen.
Wie verbessert RAG-MCP die Genauigkeit der Werkzeugauswahl?
Das RAG-MCP-Papier (arXiv 2505.03275) zeigte, dass die abrufbasierte Werkzeugauswahl eine Genauigkeit von 43,13 % gegenüber 13,62 % für die Schema-Injection-Baseline auf demselben Benchmark erreichte – mehr als das Dreifache der Genauigkeit mit weniger als der Hälfte der Prompt-Tokens. Das Modell sieht nur die Tools, die für die aktuelle Abfrage relevant sind, sodass seine Aufmerksamkeit nicht fragmentiert wird.
Sollte ich jetzt von MCP auf einen abrufbasierten Ansatz umsteigen?
Wenn Ihr Agent weniger als acht Tools verwendet und gut funktioniert, bleiben Sie. Wenn Sie Halluzinationsausbrüche erleben, die Token-Kosten steigen oder planen, über zehn Tools hinaus zu skalieren, beginnen Sie jetzt mit dem Prototyping einer Abrufschicht wie Corsair. Der Übergangspunkt ist nicht elegant – die Leistung nimmt schnell ab, sobald Sie ihn überschreiten, und die Migration ist je nach alter Architektur einfacher, bevor Sie Produktionsverkehr haben.
Lasst uns zusammenarbeiten
Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.
- Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Unternehmenslösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
