Lookup Tools
Suchen konkrete Entitäten, Dokumente, Kunden, Systeme oder Begriffe. Gut für kontrollierte Einstiegspunkte in den Graphen.
Architektur-Detail · Agenten-Kontext
Ein Neo4j-Graph wird per MCP-Server als Tool-Set für Agenten bereitgestellt: Graphabfragen, Entitätslookups und Traversals werden als MCP-Tool-Calls verfügbar. Agenten fragen den Graphen kontextbezogen ab, ohne direkten Datenbankzugriff. Standardisiert, modular, auswechselbar.
Kuratierte Architekturentscheidung auf Basis der lokalen Compass-Daten
Relevant wenn
Wenn mehrere Agenten oder LLMs denselben Wissensgraphen nutzen sollen und Vendor-Unabhängigkeit bei der Agenten-Schicht wichtig ist.
Quellenlage
Reales Integrationsmuster auf Basis von MCP und Graphdatenbanken. Der Compass beschreibt daraus die konkrete Variante: Graphabfragen als kontrollierte Agenten-Tools.
Mehrere Agenten oder LLM-Instanzen sollen denselben strukturierten Graphkontext über ein standardisiertes Protokoll nutzen.
Systemkarte
Die Motion Map verdichtet das Muster auf seine wichtigsten Stationen: Eingabe, Daten- oder Graphschicht, Retrieval, Kontrolle und Antwort. Sie ist bewusst kleiner als die Referenzarchitektur darunter und soll zuerst die Leserichtung und die Systemgrenzen sichtbar machen.
Architekturblick
Diese Seite ist eine Entscheidungshilfe für den Stack. Der Blick liegt auf Datenfluss, Failure Modes, Evaluation, Tooling und dem nächsten sinnvollen Migrationsschritt.
Agenten greifen nicht direkt auf den Graphen zu. Sie nutzen eng definierte MCP-Tools, die Parameter prüfen, Graphabfragen ausführen und begrenzte Subgraphen oder Pfade zurückgeben.
Read-only Lookup-Tools einführen, danach Traversal- und Explanation-Tools. Mutationen erst mit Review, Audit und Rollback erlauben.
Referenzarchitektur
In dieser Architektur ist der Graph nicht direkt Teil des Prompts. Er wird als kontrolliertes Tool-Set verfügbar gemacht. MCP ist dabei die Schnittstelle: Der Agent nutzt definierte Graphwerkzeuge mit klaren Parametern, Grenzen, Rechten und Rückgabeformaten.
01
Der Knowledge Graph liegt in Neo4j, Neptune, Memgraph oder einer anderen Graphplattform. Agenten greifen nicht direkt auf die Datenbank zu.
02
Graphabfragen werden als fachlich benannte Tools exponiert: Entität suchen, Nachbarschaft laden, Pfad erklären, Quellen holen oder Beziehung prüfen.
03
Jedes Tool erhält klare Parameter, Rückgabeformate, Limits und Fehlermeldungen. Der Agent bekommt nicht beliebige Cypher- oder SPARQL-Freiheit.
04
Das Modell entscheidet anhand der Tool-Beschreibung, welches Graphwerkzeug zur Frage passt. Gute Tool-Beschreibungen sind hier Architekturarbeit.
05
Der MCP-Server liefert kontrollierte Subgraphen, Pfade, Trefferlisten oder Quellenpakete, die das Modell in die Antwort einbauen kann.
06
Tool-Calls, Parameter, Ergebnisse, Fehler und Latenzen werden beobachtbar gemacht, damit Agentenverhalten debuggt und begrenzt werden kann.
Implementierungs-, Integrations- und Betriebsaufwand.
Qualität, Struktur und Zugänglichkeit der Daten vor dem Pilot.
Erfahrung mit RAG, Graphdenken, Infrastruktur und Evaluation.
Direkte DB-Integration reicht oder Tool-Auswahl noch nicht zuverlässig ist.
MCP-Tooling ist noch jung — SDKs und Debugging-Werkzeuge weniger ausgereift als direkte DB-Integrationen. Netzwerk-Overhead je Tool-Call addiert sich bei vielen Graphabfragen. Tool-Beschreibungen müssen sorgfältig formuliert sein, damit der LLM sie korrekt auswählt.
Tool-Modell
Ein MCP Graph-Backend wird nicht dadurch gut, dass es viele Tools hat. Es wird gut, wenn jedes Tool eine klare fachliche Aufgabe hat und der Agent das passende Werkzeug zuverlässig auswählen kann.
Suchen konkrete Entitäten, Dokumente, Kunden, Systeme oder Begriffe. Gut für kontrollierte Einstiegspunkte in den Graphen.
Erweitern einen bekannten Knoten um Nachbarn, Pfade oder Abhängigkeiten. Wichtig für Mehrsprung-Kontext ohne freie Graphabfragen.
Liefern Quellen, Beziehungspfade und Begründungen. Diese Tools helfen, Antworten nachvollziehbar zu machen.
Schreiben oder aktualisieren Graphwissen. Diese Tools sind am riskantesten und brauchen Rollen, Reviews, Idempotenz und Audit-Logs.
Qualitätshebel
Das Risiko liegt in Datenbank, zu breiten Tools, unklaren Beschreibungen, fehlenden Berechtigungen und schlechter Beobachtbarkeit. Dann wählt der Agent zwar ein Tool, aber nicht unbedingt das richtige oder erlaubte.
Ein Tool namens queryGraph ist zu breit. Besser sind fachliche Namen wie findCustomerRisks, getPolicyEvidence oder explainDependencyPath.
Freitextparameter öffnen Sicherheits- und Qualitätsrisiken. Gute Tools begrenzen IDs, Typen, Tiefe, Zeiträume, Rollen und Ergebnisgröße.
Der Graph darf nicht mehr preisgeben, nur weil ein Agent fragt. Rechte müssen vor der Abfrage und in der Rückgabe wirken.
Teste die Graphabfrage und ob das Modell bei echten Fragen das richtige Tool auswählt und falsche Tools vermeidet.
Ausbaustufen
Der sinnvollste Einstieg ist fast immer read-only. Schreibende oder autonome Agenten-Graph-Backends sollten erst entstehen, wenn Berechtigungen, Validierung, Review und Auditierbarkeit belastbar sind.
Stufe 1
Starte mit sicheren Such- und Lookup-Tools. Keine Schreiboperationen, klare Limits, beobachtbare Aufrufe.
Stufe 2
Ergänze Pfad- und Quellen-Tools, damit Antworten korrekt und nachvollziehbar werden.
Stufe 3
Wenn mehrere Agenten denselben Graphen nutzen, werden Tool-Verträge, Versionierung und Rate Limits wichtiger.
Stufe 4
Schreibende Tools erst mit Rollenmodell, Validierung, Review, Audit-Trail und Rollback einführen.
In welchem Kontext das Muster typischerweise Sinn ergibt und welchen Beitrag es dort leistet.
Ein Agent soll Fragen an Neo4j stellen, ohne direkten Datenbankzugriff im Prompt zu haben.
MCP stellt kontrollierte Tools für Graphkontext bereit.
Mehrere Agenten oder Anwendungen sollen denselben Wissensgraph nutzen.
Das Backend kapselt Zugriff, Berechtigungen und Abfrageformen.
Ein Agent bekommt ein Tool getCustomerRiskContext(customerId). Das Tool lädt erlaubte Risiken, betroffene Verträge und Quellen aus dem Graphen.
Der Agent muss keine freie Datenbankabfrage formulieren. Das MCP-Backend liefert kontrollierten Graphkontext in einer stabilen Form.
MCP-Tools fachlich benennen
Abfragegrenzen pro Tool definieren
Tool-Auswahl mit realen Prompts testen