Tomaz Bratanic, der bei Neo4j arbeitet, stellt in seinem Artikel die These auf, dass dedizierte MCP-Server für LLM-Agenten in vielen Produktiv-Workflows die falsche Architektur sind. Das klassische Muster – für jeden Dienst (GitHub, Jira, Slack, Postgres, Neo4j) einen eigenen MCP-Server mit einer Handvoll vordefinierter Tools zu betreiben – stamme aus einer Zeit, als Modelle noch mit freiem Shell-Zugang überfordert waren. Heute lesen aktuelle Modelle --help-Seiten, kennen gängige CLIs aus dem Training und können Bash-Pipelines eigenständig zusammensetzen. Als konkretes Beispiel vergleicht Bratanic den offiziellen Neo4j-MCP-Server mit neo4j.sh (dem offiziellen Neo4j-CLI): Bei drei Datenbankumgebungen (dev, staging, prod) erzeugt der MCP-Ansatz zwölf Tool-Schemas pro Turn im Context Window, während die CLI-Variante dasselbe per for-Loop mit einem einzigen Binary und drei Credential-Profilen erledigt. Ein weiterer Nachteil von MCP zeigt sich beim Query-Chaining: Zwischenergebnisse landen im Modell-Kontext statt direkt in der nächsten Query verarbeitet zu werden. Bratanic räumt ein, dass ein Terminal-Zugang für Agenten eine deutlich größere Angriffsfläche bietet (Prompt Injection, Blast Radius) und entsprechende Absicherung – Sandboxing, Allowlists, Read-only-Rollen – erfordert. Das MCP-Protokoll selbst schreibe enge Einzel-Tools nicht vor; die Implementierungen gravitierten aus historischen Gründen dorthin.