mcp-chat

Zusammenfassung der Implementierungsmethoden für einen Neo4j-basierten Chatbot-MCP-Server.

Prinzipien der MCP-Server-Erstellung

Tool-Design — Entwerfen Sie das Verhalten des Modells, nicht die API

• Spiegeln Sie keine REST-API wider. Bündeln Sie nicht ein Tool pro Endpunkt, sondern nach Arbeitseinheiten, die das Modell ausführen soll.

• Wenige Tools, lange Beschreibungen. Die Beschreibung ist ein Dokument, das angibt, wann es verwendet werden soll/nicht verwendet werden soll, Beispiele für Argumente und das Rückgabeformat. Die Beschreibung ist der Prompt.

• Das Ausgabeformat wird innerhalb des Token-Budgets entworfen. Statt Roh-JSON-Dumps in einem für das Modell lesbaren Format formatieren, für große Ergebnisse limit- und Paginierungsparameter vorsehen.

Standardmuster für die Struktur

• Transporttrennung — lokal stdio, remote Streamable HTTP. Wenn Serverlogik und Transport getrennt sind, ist es einfacher, beide zu unterstützen.

• Eingabevalidierung mittels Schema — das TS SDK deklariert Tool-Argumente mit Zod-Schema. Validierung nicht manuell schreiben.

• Fehler werden nicht per Throw, sondern als Ergebnis mit isError: true zurückgegeben. Damit das Modell die Fehlermeldung lesen und wiederholen kann, enthalten Sie in der Nachricht Ursache und Lösungsweg.

• Bei stdio ist stdout der Protokollkanal. Logs müssen auf stderr. Ein einziger console.log kann den Server zum Absturz bringen.

• Gefährliche Operationen werden nicht durch Prompts, sondern durch Code blockiert. Z.B. Verweigerung von Schreibanweisungen in einem Read-Only-Tool, erzwungene LIMIT-Einfügung.

Entwicklungs-Workflow

1. Manuelles Testen mit MCP Inspector — npx @modelcontextprotocol/inspector node dist/index.js

2. Validierung der Tool-Auswahlszenarien mit einem echten Modell — wenn das Modell ein falsches Tool auswählt, korrigieren Sie die Beschreibung, nicht den Code.

3. Die Geschäftslogik (Query-Validator, Formatierer) wird mit MCP-unabhängigen Unit-Tests validiert.

Related MCP server: Neo4j GraphRAG MCP Server

4 Implementierungsansätze

1. Verwendung des offiziellen Neo4j MCP-Servers

Methode, bei der der von Neo4j offiziell bereitgestellte MCP-Server nur durch Konfiguration verbunden wird.

• mcp-neo4j-cypher — Bietet Tools (get_schema, read_cypher, write_cypher), mit denen das LLM das Schema abfragen und Cypher direkt generieren und ausführen kann.

• mcp-neo4j-memory — Server für Langzeitgedächtnis, der Entitäten/Beziehungen aus Gesprächen als Wissensgraph speichert.

2. Eigener MCP-Server im Text2Cypher-Stil

Methode, bei der Sie einen eigenen MCP-Server erstellen, aber das Tool eine universelle Struktur von 'natürlichsprachliche Frage → Cypher-Generierung → Ausführung' hat. Ähnlich wie der offizielle Server, aber Sie können folgendes direkt steuern:

• Einspielen der Schema-Beschreibung (Bereitstellung der Graphenstruktur im Prompt)

• Query-Validierung (Read-Only erzwingen, LIMIT erzwingen)

• Ergebnisformatierung

3. Domain-spezifischer Tool-Ansatz

Methode, bei der dem LLM kein Cypher überlassen wird, sondern domain-spezifische Tools vorab definiert werden. Innerhalb jedes Tools werden nur parametrisierte Cypher ausgeführt.

search_person(name)          → 파라미터화된 Cypher 실행
get_relationships(id, depth) → 파라미터화된 Cypher 실행
find_path(from, to)          → shortestPath 쿼리 실행

4. GraphRAG-Ansatz

Methode, bei der nach einer Ähnlichkeitssuche mit dem Vektorindex von Neo4j ein einzelnes Tool retrieve(query) bereitgestellt wird, das den Graphen von den gefundenen Knoten aus erweitert (Nachbarknoten, Beziehungen) und Kontext erstellt.

retrieve(query)
  1. query 임베딩 → 벡터 인덱스 유사도 검색
  2. 매칭된 노드에서 그래프 확장 (이웃 노드, 관계 수집)
  3. 수집된 서브그래프를 컨텍스트로 반환

Empfohlene Kombination

In der Praxis ist 2 + 3 gemischt ein häufiges Muster. Häufig gestellte Fragen werden mit domain-spezifischen Tools behandelt, der Rest mit Read-Only-Text2Cypher als Fallback.

Stack-Referenz

• TypeScript — @modelcontextprotocol/sdk

• Python — FastMCP