nautilus-trader MCP server

Was das ist

Ein MCP-Server (Model Context Protocol), der einem LLM (Claude Code, Codex CLI, etc.) zwei Möglichkeiten bietet, Dinge in nautilus_trader nachzuschlagen, während es Strategiecode dagegen schreibt:

• Codesuche (index.py) -- strukturelle Suche im tatsächlichen Quellcode (Python + Rust) anhand des Symbolnamens. Keine Fuzzy-Text-/Embedding-Suche: Sie findet die echte Klasse/Funktion/Struct und gibt den Docstring oder vollständigen Quellcode zurück.

• Dokumentationssuche (rags/) -- semantische (Embedding-basierte) Suche über die Markdown-Dokumente des Projekts (Konzepte, Anleitungen, Tutorials), für Fragen wie „Wie ...", die sich nicht auf einen einzelnen Symbolnamen abbilden lassen.

Related MCP server: MCPyDoc

So funktioniert es

• index.py startet zwei echte Sprachserver als Unterprozesse und spricht direkt LSP (JSON-RPC über stdio) mit ihnen -- pylsp für den Python-Quellcode unter nautilus_trader/python/nautilus_trader, rust-analyzer für den Rust-Quellcode unter nautilus_trader/crates. documentSymbol findet Klassen/Funktionen/Structs/Impls auf oberster Ebene; hover holt den Docstring (nur Python -- siehe Bekannte Einschränkungen). Ergebnisse werden in .code_index_cache.json zwischengespeichert, da der Aufbau etwa 25 s dauert (hauptsächlich rust-analyzer über ~2600 Dateien).

• rags/rag_build.py teilt jede Datei unter docs/ in Blöcke und erstellt einen dspy.retrievers.Embeddings-Index (Gemini embeddings), gespeichert in rags/ (config.json + corpus_embeddings.npy) sowie eine shape.json, die die ursprüngliche Ordnerstruktur festhält, damit rags/search.py auf einen Unterordner filtern kann.

• mcp_server.py bindet beide in 5 MCP-Tools ein: search_code, get_code_doc, get_code_source, search_docs, show_doc_keys.

Einrichtung

git clone https://github.com/GwangPyo/NautilusTraderMCP.git
cd NautilusTraderMCP
cp .env.example .env   # fill in GEMINI_API_KEY (and OPENAI/ANTHROPIC if you use load_model)
./install.sh           # conda env "mcp" + deps, nautilus_trader clone, code index, doc index

install.sh ist idempotent: Bei erneuter Ausführung überspringt es den nautilus_trader-Klon, die docs/-Kopie und den (kostenpflichtigen) Aufbau der Dokument-Embeddings, falls diese bereits existieren. Setzen Sie ENV_NAME=<name>, um einen anderen Conda-Env-Namen zu verwenden (wird für Tests verwendet, damit es die echte mcp-Umgebung nicht anfasst).

Ein Env-Manager ist nicht erforderlich -- uv venv && uv pip install -e . funktioniert ebenfalls; install.sh standardisiert lediglich auf Conda für eine reproduzierbare Einrichtung mit einem einzigen Befehl.

Bei einem Client registrieren

./add_claude.sh   # claude mcp add
./add_codex.sh    # codex mcp add

Beide verweisen den Client einfach über stdio auf <conda mcp env>/bin/python3 mcp_server.py.

Bekannte Einschränkungen / TODO

• .code_index_cache.json und rags/{config.json,corpus_embeddings.npy,shape.json} haben keine Invalidierung -- wenn sich nautilus_trader/ oder docs/ ändern, müssen Sie die Cache-Dateien von Hand löschen und das Skript erneut ausführen, um die Änderungen zu übernehmen.

• Keine automatisierten Tests -- alles wurde bisher von Hand verifiziert (frisches Conda-Env, frisches uv-Env, echter MCP-Client über stdio).

• nautilus_trader/ wird von main geklont (nicht fixiert) -- kann mit der Zeit abweichen; derzeit wird es gegen keinen bekannten guten Commit/Tag geprüft.