Wenn Sie möchten, dass ein LLM-Agent Anfang 2026 mit einem System kommuniziert, müssen Sie dafür einen MCP-Server installieren.
GitHub. Jira. Locker. Linear. Postgres. Neo4j. Jeder wird mit einem Server geliefert, der ein übersichtliches Menü an Instruments bereitstellt. create_issue, list_pull_requests, merge_pull_request, get_repository, search_codeusw., und Sie weisen Ihren Agenten darauf hin.
Es ist ein großartiges Onboarding-Erlebnis. Für überraschend viele reale Arbeitslasten ist es auch die falsche Kind.
Die These ist kurz: Das MCP-Design verpackt normalerweise jeden Dienst als einen Stapel dedizierter Instruments. Eine CLI gibt dem Agenten ein wirklich flexibles Software an die Hand. Bei den heutigen Modellen gewinnt das versatile Werkzeug.
Die beiden Formen fordern das Modell auf, unterschiedliche Arbeiten auszuführen. Mit einem Haufen dedizierter Instruments muss der Agent es einfach tun Wählen Sie das Richtige aus einem Menü aus. Bei einem flexiblen Werkzeug muss es so sein Finden Sie heraus, wie Sie die Teile selbst zusammensetzen. Der zweite Teil conflict früher der schwierigste. Modelle halluzinierten Flaggen, verloren bei langen Pipelines den Faden und lasen Hilfetexte falsch, daher conflict es eine vernünftige Verteidigung, jede Operation in ein vorgefertigtes Software zu packen. Das stimmt einfach nicht mehr. Heutige Modelle lesen a --help Seite bzw SKILL.md Wenn nötig, kennen Sie die kanonischen CLIs aus dem Coaching, reihen Sie Bash ohne Aufsicht aneinander und versuchen Sie es erneut, wenn ein Flag falsch ist. Der schwierige Teil wurde einfach, der einfache Teil conflict immer einfach, und all diese ordentlich verpackten Instruments blähen den Kontext des Modells jetzt größtenteils umsonst auf.
Natürlich gibt es nicht nur Rosen und Sonnenschein. Durch die Übergabe eines Terminals erhält der Agent auch einen viel größeren Explosionsradius. Die gleiche Flexibilität, die es beim Komponieren ermöglicht gh | jq | xargs in etwas Nützliches zu verwandeln, lässt sich durch eine schnelle Injektion auch zu etwas viel Schlimmerem als einer feindlichen Cypher-Anfrage machen. Additionally ja, es gibt einen Kompromiss, und Sie müssen tatsächlich darüber nachdenken (Sandbox, Zulassungsliste, separater Betriebssystembenutzer, schreibgeschützte Rolle in der Datenbank, das Übliche).
Wenn Sie dem Agenten jedoch auf einigermaßen sichere Weise ein Terminal zur Verfügung stellen können, hat die versatile Seite immer noch die Nase vorn.
Wo CLI glänzt
Das gleiche Muster „Verpacken Sie einen Dienst als einen Stapel dedizierter Instruments“ zeigt sich überall dort, wo MCP dies tut. Postgres MCPs vs. psql. Kubernetes MCPs vs. kubectl. Dateisystem-MCPs vs. cat, ls, mv, grep mit Rohren verklebt. Jedes Mal derselbe Instinkt, jedes Mal das gleiche CLI-Gegenstück. Und auch die gleichen drei Fehlermodi, denn es geht nicht wirklich um ein einzelnes Produkt.
Nichts in der MCP-Spezifikation erfordert tatsächlich diesen Ansatz der Anhäufung dedizierter Instruments. Das Protokoll verlangt nach eingegebenen Werkzeugen, mehr nicht; Es sagt nichts darüber aus, wie schmal jedes Werkzeug sein muss. Aus historischen Gründen tendieren Implementierungen einfach zu vielen kleinen, schmalen Instruments. Sie können versatile Instruments erstellen, die eine einzige ausdrucksstarke Eingabe erfordern, die der Agent so formt, wie er möchte, und in den meisten Fällen sollten Sie das wahrscheinlich auch tun.
Um es konkret zu machen, schauen wir uns ein Beispiel einer Lochfraßbildung an Neo4j MCP-Server gegen Neo4j-CLI.
Haftungsausschluss vorab: Ich arbeite bei Neo4j. Die Wahl dient nur der Bequemlichkeit, aber die Erkenntnisse gelten auch für die meisten anderen CLIs.
Der Neo4j MCP-Server ist der offizielle Server, der Neo4j Agenten über MCP zugänglich macht und eine Handvoll dedizierter Instruments wie Leseabfrage, Schreibabfrage und Schemaabruf bereitstellt. neo4j.sh ist die offizielle Befehlszeilenschnittstelle für Neo4j, eine einzelne Binärdatei, die Sie in einem Terminal mit Anmeldeinformationsprofilen für jede Datenbank ausführen, mit der Sie kommunizieren. Um den Vergleich ehrlich zu halten, betrachten wir nur das Leseabfrage- und Schemapaar auf der MCP-Seite im Vergleich zum Äquivalent question Anrufung in neo4j.sh. Dieselben Vorgänge, dieselbe Datenbank, derselbe Cypher, der über das Kabel geht. Das Einzige, was sich ändert, ist, ob der Agent sie über ein typisiertes Toolschema oder über eine an eine Shell übergebene Zeichenfolge erreicht.
Umgebungsübergreifende Abfragen
Wir haben bereits gesehen, wie ein Haufen dedizierter Instruments das Kontextfenster mit Beschreibungen verschlingt und dass einige Server jetzt verzögerte Instruments ausliefern, um diese Kosten zu verschieben, bis der Agent tatsächlich nach ihnen greift. Aber es gibt noch einen zweiten Multiplikator, über den niemand spricht: Was passiert, wenn Sie mit mehr als einer Instanz desselben Dienstes kommunizieren möchten? Mit MCP wächst die Anzahl der Instruments nicht nur mit den Funktionen, sondern auch mit den Umgebungen.
Der Agent möchte eine Knotenanzahl von Dev, Staging und Prod. Durch MCP stehen Sie auf neo4j-mcp-server professional Umgebung, wobei jedes seine vier Werkzeugschemata bei jeder Runde in den Kontext des Agenten überträgt. Drei Datenbanken sind zwölf Schemata im Modellfenster, dieselben vier Schemata dreimal, bevor der Agent etwas getan hat.
Über die CLI ist es ein for Schleife:
$ for c in dev staging prod-ro; do
neo4j-cli question -c $c --format toon
"MATCH (n) RETURN rely(n) AS nodes"
completedEine Binärdatei, drei Anmeldeinformationsprofile, keine Kontextkosten professional Runde. Das Hinzufügen einer vierten Umgebung ist eine weitere credential dbms addnicht ein weiterer MCP-Serverprozess. Die gleiche Kind lässt sich auf jeden Arbeitsablauf übertragen, bei dem es darum geht, „N ähnliche Dinge zu erreichen“: Snapshot-Erstellung eines Produkts vor einer riskanten Bereitstellung, Differenzierung des Schemas zwischen Staging und Produkt, Durchführung einer Zustandsprüfung für jede Datenbank, die dem Agenten bekannt ist.
Verketten von Abfragen
Angenommen, der Agent untersucht ein bekanntes Betrugskonto: Suchen Sie anhand eines einzelnen Seeds jedes Konto, mit dem Transaktionen getätigt wurden, und finden Sie dann heraus, welches andere Konten, mit denen diese Gegenparteien am häufigsten Geschäfte tätigen. Zwei Abfragen für dieselbe Datenbank, wobei die Parameter der zweiten die Ausgabe der ersten sind.
Durch MCP muss das Modell das Rohr sein. Es ruft read-cypherkommt das Ergebnis als Liste von beispielsweise 80 Gegenpartei-IDs zurück. Diese 80 IDs befinden sich jetzt im Kontext des Modells, das Modell formatiert sie in den Parameter für die Sekunde read-cypher Rufen Sie an, und erst dann können zwei Abfragen ausgeführt werden. Die Zwischenliste begleitet die Konversation wörtlich, und jede zusätzliche ID ist eine weitere Kontextzeile, für die der Agent bezahlt, unabhängig davon, ob er sie jemals wieder liest oder nicht.
Durch die CLI ist die Pipe ein Literal |:
$ neo4j-cli question -c prod-ro --format json
--param "seed=acct_19f3"
"MATCH (:Account {id: $seed})-(:TRANSACTED)-(c:Account)
WHERE c.id <> $seed
RETURN acquire(DISTINCT c.id) AS counterparties"
| neo4j-cli question -c prod-ro --params-from-stdin
"MATCH (a:Account)-(:TRANSACTED)-(b:Account)
WHERE a.id IN $counterparties
AND NOT b.id IN $counterparties + ('acct_19f3')
RETURN b.id, rely(DISTINCT a) AS edges_into_cluster
ORDER BY edges_into_cluster DESC LIMIT 20"--params-from-stdin liest das JSON-Ergebnis der vorherigen Abfrage und bindet es als Parameter für die nächste. Die Liste der Gegenparteien geht nie in den Kontext des Modells ein, die Token-Kosten des Agenten sind die gleichen, unabhängig davon, ob der Cluster 5 oder 500 Gegenparteien hat.
Ab diesem Zeitpunkt fühlt sich die Schale wie eine ganz andere Werkzeugkategorie an. Der Agent wählt nicht mehr aus einem Menü von Vorgängen aus, sondern erstellt Pipelines, und die Zwischendaten müssen nie mehr an die Oberfläche gelangen. Eine zweistufige Abfrage wird zu einer |. Aus einem Fan-Out wird ein for Schleife. Ein Be a part of zwischen zwei Datenbanken wird zu einer einzigen question in ein anderes mit geleitet --params-from-stdin. Jeder davon wäre drei oder vier MCP-Roundtrips, wobei jedes Zwischenergebnis durch das Kontextfenster angezeigt wird, und an diesem Punkt hat der Agent mehr Token für das Mischen von Zeilen aufgewendet, als darüber nachzudenken.
Über viele CLIs hinweg weiterleiten
Gleiches Drawback, größerer Maßstab. Angenommen, der Agent möchte die neuesten GitHub-Probleme eines Projekts in Neo4j umwandeln: an :Situation Knoten professional Ticket, a :Consumer Knoten professional Autor, a :TAGGED Beziehung professional Etikett. Die Daten befinden sich in einer CLI (gh), will umgestalten (jq tut das) und landet in einer anderen CLI (neo4j-cli). Drei verschiedene Werkzeuge in einer Linie. Über MCP greifen Sie auf den MCP-Server von GitHub zu, um die Problemliste abzurufen. Jeder Problemtext landet im Kontext des Modells, das Modell extrahiert die gewünschten Felder usw write-cypher Wird einmal professional Ausgabe ausgelöst. Hunderte von Rundgängen durch das Modell, wobei jedes Themengremium unterwegs an der Diskussion beteiligt ist.
Über die CLI drei Programme in einer Pipe:
$ gh situation record --repo neo4j/neo4j --limit 100
--json quantity,title,creator,labels
| jq -c '.()'
| whereas learn situation; do
neo4j-cli question --rw -c prod
--param "knowledge=$situation"
"WITH apoc.convert.fromJsonMap($knowledge) AS i
MERGE (n:Situation {quantity: i.quantity}) SET n.title = i.title
MERGE (u:Consumer {login: i.creator.login})
MERGE (u)-(:OPENED)->(n)
FOREACH (label IN i.labels |
MERGE (l:Label {title: label.title})
MERGE (n)-(:TAGGED)->(l))"
completedgh zieht die Themen, jq formt jede einzelne in eine einzelne JSON-Zeile um, die whereas Schleife übergibt jede Zeile an neo4j-cli als Cypher-Parameter. Das Modell schreibt dieses Skript einmal und geht dann davon; Die Daten fließen über die Bash, nicht über den Agenten. Hundert oder zehntausend Ausgaben, die Token-Kosten des Agenten sind gleich.
Die Kind lässt sich weit über GitHub hinaus verallgemeinern. Tauschen gh für jede andere CLI, die JSON ausgibt (jira situation record, linear, curl gegen einen Webhook, Ihren eigenen internen dump Befehl), tauschen Sie das Cypher-Muster für die Datenbank aus, die Sie erstellen, und die Pipeline trägt es. Zwei MCP-Instruments können nicht miteinander kommunizieren. Zwei CLIs können das und zehn auch.
Die Terminalsteuerung ist leistungsstark, und das ist der Haken
Das Terminal ist keine feste Oberfläche, sondern das flexibelste Werkzeug, das Sie einem Agenten geben können, da es mit allem anderen auf der Field zusammenarbeitet.
Diese Kraft ist auch der Haken. Ein falsch eingesetztes flexibles Werkzeug verursacht flexiblen Schaden. Mit einem großartigen Terminalzugriff geht die offensichtliche Verantwortung einher: Sandboxen Sie die Shell, setzen Sie die tatsächlich gewünschten Verben auf die Zulassungsliste, führen Sie den Agenten als separater Betriebssystembenutzer aus, binden Sie Anmeldeinformationen an Rollen, die physisch nicht in der Lage sind, die destruktive Aufgabe zu erfüllen. Nichts davon ist neu, es handelt sich lediglich um die Systemadministratorhygiene, die auf ein LLM angewendet wird, das schnell tippt. Und wenn Sie das alles nicht können, ist ein MCP-Server mit kleiner fester Oberfläche immer noch die richtige Antwort; Die Garantie auf Protokollebene, dass der Agent dies nicht kann cat ~/.ssh/id_rsa ist eine echte Sache.
Der allgemeinere Punkt gilt auch dann, wenn Sie vollständig innerhalb von MCP bleiben. Der Grund, warum das Terminal gewinnt, ist nicht, dass Bash etwas Besonderes ist, sondern dass Bash ein Software mit sehr flexibler Eingabe ist. Pipes, Variablen, Substitution, Schleifen. Das ist die Kind, die es wert ist, kopiert zu werden. Betrachten Sie das Terminal als MCPs Grenzfall und entwerfen Sie es entsprechend: weniger Instruments, jedes einzelne akzeptiert ausdrucksstarke Eingaben, der Agent übernimmt die Erstellung, anstatt dass Sie jede Kombination im Voraus antizipieren. Bei den meisten MCP-Servern handelt es sich um eine lange Liste schmaler Endpunkte, weil die zugrunde liegende API bereits so gestaltet wurde, und nicht, weil der Agent auf diese Weise besser funktioniert. Die Server, die intestine altern, werden diejenigen sein, die sich bewusst für eine kleinere, ausdrucksstärkere Oberfläche entschieden haben.
Alle Bilder in diesem Blogbeitrag wurden vom Autor erstellt.