QuantConnect MCP mit Claude Strategien agentisch testen.

Mit dem QuantConnect MCP-Server kann Claude direkt auf der Plattform QuantConnect arbeiten: Projekte anlegen, Strategiecode schreiben, kompilieren, Backtests starten, Ergebnisse und Logs lesen und Parameter-Optimierungen anstoßen. Damit wird aus einem Chat-Assistenten ein Agent, der den Kreislauf Idee → Code → Backtest → Auswertung selbstständig durchläuft. Stand Oktober 2026 empfiehlt QuantConnect den gehosteten Remote-Server mit Browser-Anmeldung oder die in VS Code eingebettete Variante; das frühere Docker-Image gilt laut GitHub-Repository vorerst als veraltet. Technisch ist der Einstieg schnell erledigt. Das eigentliche Problem liegt woanders: Ein Agent, der Dutzende Varianten testet, findet fast immer eine, die im Backtest glänzt. Dieser Artikel zeigt Einrichtung und Arbeitsablauf, erklärt, warum agentisches Backtesting die Gefahr der Überanpassung vervielfacht, und welche Regeln ich für sauberes Research mit KI-Agenten anwende, inklusive der Frage, ob Sie Live-Deployment-Rechte überhaupt freigeben sollten.

Was ist der QuantConnect MCP-Server?

QuantConnect ist eine Cloud-Plattform für algorithmischen Handel. Ihr Kern ist die Open-Source-Engine LEAN, in der Strategien in Python oder C# geschrieben, mit historischen Daten getestet und in den Live-Betrieb gebracht werden. Der MCP-Server ist die Brücke zwischen einem Sprachmodell und der QuantConnect-API. MCP steht für Model Context Protocol, einen offenen Standard, über den KI-Assistenten externe Werkzeuge aufrufen. Mit der Spezifikation vom 28.07.2026 wurde der Protokollkern zustandslos, und die Autorisierung wurde an mehreren Stellen enger an OAuth-Standards ausgerichtet.

In der Ankündigung spricht QuantConnect von über 60 API-Endpunkten. Die aktuelle Dokumentation gliedert die Werkzeuge in Gruppen:

• Projekte und Dateien: Projekte anlegen, lesen, aktualisieren; Dateien erstellen, bearbeiten, durchsuchen.
• Kompilieren und Backtesting: create_compile, create_backtest, read_backtest, read_backtest_orders, search_backtest_logs und weitere.
• Optimierung: Parameter-Optimierungen anlegen, lesen, auflisten, löschen.
• Research: Jupyter-Notebooks und einzelne Zellen anlegen, ausführen, lesen, inklusive Diagramme.
• Daten und Umgebung: verfügbare Datensätze und unterstützte Bibliotheken abfragen.
• Live-Trading: Deployment starten, Status und Bestände lesen, Logs durchsuchen, stoppen, liquidieren.
• Sonstiges: Object Store, Benachrichtigungen per E-Mail, SMS und Telegram, sowie „Skills“, also vorgefertigte Anleitungen, die der Agent bei Bedarf lädt.

Der Agent arbeitet damit nicht auf Ihrem Rechner, sondern in Ihrem QuantConnect-Konto. Code, Daten und Backtests liegen in der Cloud. Das ist praktisch, weil Sie keine eigene Datenhaltung brauchen, bedeutet aber auch: Was der Agent darf, darf er mit Ihrem Konto.

Wie richte ich QuantConnect MCP mit Claude ein?

Stand Oktober 2026 gibt es drei Wege. Welcher passt, hängt davon ab, ob Sie lieber im Terminal, in VS Code oder mit einem älteren Setup arbeiten.

Die Anleitung von QuantConnect beschreibt das Hinzufügen über die Connector-Einstellungen mit anschließender Autorisierung im Browser. Im Terminal funktioniert der allgemeine Claude-Code-Befehl für HTTP-Server; die Anmeldung starten Sie danach über /mcp im Browser, ein API-Token müssen Sie nicht in eine Konfigurationsdatei schreiben:

claude mcp add --transport http quantconnect https://www.quantconnect.com/api/v2/mcp
# danach in Claude Code:
/mcp

Die Docker-Variante funktioniert weiterhin nach dem älteren Muster: Der Client startet einen Container mit QUANTCONNECT_USER_ID, QUANTCONNECT_API_TOKEN und AGENT_NAME als Umgebungsvariablen, auf Apple-Rechnern mit M-Chip mit --platform linux/arm64. Der Quellcode steht unter Apache-2.0-Lizenz. Für neue Setups würde ich diesen Weg nicht mehr wählen: Ein API-Token im Klartext in einer Konfigurationsdatei ist schlechter als eine Browser-Anmeldung, die Sie jederzeit widerrufen können. Prüfen Sie Planvoraussetzungen und Kosten direkt auf der Preisseite von QuantConnect.

Wie sieht ein sauberer Workflow vom Notebook zum Backtest aus?

Ein sinnvoller Ablauf trennt Forschung und Test. Der Agent soll nicht in einer Schleife Code ändern und Backtests starten, bis eine Zahl gut aussieht. Er soll eine vorher formulierte Hypothese prüfen. Bewährt hat sich diese Reihenfolge:

1. Hypothese schriftlich festlegen: Welcher Markteffekt, welches Universum, welcher Zeitraum, welche Kennzahl entscheidet. Das schreiben Sie, nicht der Agent.
2. Daten im Notebook prüfen: Der Agent legt ein Research-Notebook an, lädt die Daten und prüft Verfügbarkeit, Lücken und Verteilungen. Die Jupyter-Werkzeuge liefern auch Diagramme zurück.
3. Strategie implementieren: Der Agent schreibt den LEAN-Code im Projekt und kompiliert. Kompilierfehler kann er anhand der Fehlermeldungen selbst beheben.
4. Ein Backtest auf dem Entwicklungszeitraum: Ergebnisse, Orders und Logs liest der Agent über read_backtest, read_backtest_orders und search_backtest_logs und fasst sie zusammen.
5. Plausibilitätsprüfung: Stimmen Gebühren, Slippage (die Abweichung zwischen erwartetem und tatsächlichem Ausführungspreis) und Ausführungszeitpunkte? Gibt es Trades zu unmöglichen Preisen? Hier ist der Agent stark, weil er Order-Listen schneller durchsucht als ein Mensch.
6. Erst dann Robustheit: Parametervariation in engen, vorher festgelegten Grenzen, danach ein einziger Test auf zurückgehaltenen Daten.

Typisches Beispiel: Sie geben dem Agenten eine Momentum-Hypothese für ein festes Aktienuniversum. Er baut das Notebook, schreibt den Algorithmus, findet beim ersten Backtest, dass die Ordergröße die Liquidität kleiner Werte ignoriert, und schlägt einen Filter vor. Diese Fehlersuche ist der eigentliche Gewinn. Die Entscheidung, ob der Filter fachlich gerechtfertigt ist oder nur die Kurve glättet, bleibt bei Ihnen.

Die größte Gefahr: Der Agent optimiert auf den Backtest.

Ein Mensch testet vielleicht zehn Varianten an einem Abend. Ein Agent testet hundert, ohne müde zu werden, und jede einzelne ist ein weiterer Versuch. Statistisch heißt das: Je mehr Varianten Sie prüfen, desto höher ist die Wahrscheinlichkeit, dass die beste nur durch Zufall gut aussieht. Dieses Problem heißt Mehrfachtesten (Multiple Testing) und gehört zu den häufigsten Gründen, warum Backtests im Live-Betrieb nicht halten. QuantConnect weist in der Dokumentation zur Optimierung selbst darauf hin, dass zu eng an die Vergangenheit angepasste Parameter außerhalb der Stichprobe versagen können.

Das Tückische am agentischen Arbeiten: Die Versuche sind unsichtbar. Der Agent berichtet Ihnen die beste Variante, nicht die 40 verworfenen. Er „repariert“ auch Strategien, indem er Ausnahmen einbaut, etwa einen Filter, der genau die schlechten Monate ausschließt. Jede einzelne Änderung wirkt vernünftig, in Summe entsteht eine Kurvenanpassung.

Die Deflated Sharpe Ratio von Bailey und López de Prado korrigiert die Sharpe Ratio (Überschussrendite je Einheit Schwankung) für die Zahl der Versuche und für nicht normalverteilte Renditen. Sie setzt voraus, dass Sie die Zahl der Versuche kennen. Genau deshalb müssen Sie beim agentischen Research jeden Backtest zählen. Die Backtest-Liste im QuantConnect-Projekt hilft dabei, solange der Agent keine Backtests löscht. Das Werkzeug delete_backtest sollten Sie aus diesem Grund ebenfalls sperren.

Live-Deployment bewusst ausklammern.

Der MCP-Server enthält Werkzeuge, die über Research hinausgehen. Laut aktueller Dokumentation deployt create_live_algorithm in das Paper Trading (simulierter Handel ohne echtes Geld) über die QuantConnect-Brokerage, stop_live_algorithm stoppt ohne Positionen zu schließen, liquidate_live_algorithm schließt alle Positionen zu Marktpreisen. Die ältere Docker-Variante nahm beim Deployment zusätzlich eine Brokerage-Konfiguration entgegen. Funktionsumfang und Grenzen können sich ändern, verlassen Sie sich deshalb nicht darauf, dass „live“ immer nur Paper bedeutet.

Meine Regel: Ein Research-Agent bekommt keine Werkzeuge, die Geld bewegen oder Positionen schließen. In Claude Code lässt sich das sauber über Deny-Regeln in der Projektdatei .claude/settings.json umsetzen. Deny-Regeln werden vor Ask- und Allow-Regeln ausgewertet, und eine Deny-Regel mit dem vollständigen Werkzeugnamen entfernt das Werkzeug laut Dokumentation ganz aus dem Kontext des Modells. Der Präfix richtet sich nach dem Namen, den Sie dem Server beim Hinzufügen gegeben haben:

{
  "permissions": {
    "deny": [
      "mcp__quantconnect__create_live_algorithm",
      "mcp__quantconnect__liquidate_live_algorithm",
      "mcp__quantconnect__stop_live_algorithm",
      "mcp__quantconnect__delete_backtest"
    ]
  }
}

Prüfen Sie nach dem Einrichten mit /mcp, welche Werkzeuge tatsächlich aktiv sind. Den Schritt in den Live-Betrieb lösen Sie selbst in der Oberfläche aus, zuerst im Paper Trading über mehrere Wochen, dann mit kleiner Positionsgröße. Wie man einen solchen Übergang absichert, ist ein eigenes Thema; für Wertpapierfirmen schreibt die EU mit der RTS 6 unter MiFID II etwa eine Notfall-Funktion vor, die alle offenen Orders storniert. Für Privatanleger gilt das nicht verpflichtend, als Vorbild taugt es trotzdem.

QuantConnect oder lokales Python-Backtesting?

Agentisches Backtesting funktioniert auch lokal: Claude Code schreibt Python, startet ein eigenes Backtest-Skript und liest die Ergebnisse. Mit der LEAN-CLI lässt sich zudem dieselbe Engine lokal in Docker betreiben (lean backtest, lean optimize, lean research). Die Unterschiede liegen weniger in der Technik als in Datenhaltung, Kontrolle und Kosten:

QuantConnect lohnt sich, wenn Sie schnell mit sauberen Daten forschen wollen und kein Datenteam haben. Lokales Python passt besser, wenn Sie eigene Daten, eigene Ausführungslogik oder strenge Vertraulichkeit brauchen. Wie ein eigener Backtester aufgebaut ist, beschreibt der Artikel Backtesting mit Python von Grund auf. Die Regeln gegen Überanpassung gelten in beiden Welten gleich.

Grenzen und Risiken im Überblick.

• Überanpassung: Der Agent findet Muster im Rauschen, besonders bei vielen Parametern und kurzen Zeiträumen.
• Stille Fehler: Look-ahead-Bias (Zugriff auf Daten, die zum Handelszeitpunkt noch nicht bekannt waren) oder falsche Zeitzonen fallen in einer Zusammenfassung des Agenten nicht auf. Lesen Sie den Code selbst.
• Prompt Injection: Gemeint sind Anweisungen, die in gelesenen Inhalten versteckt sind. Der Agent liest Logs, Dateien und Notebook-Ausgaben, und solche Inhalte können sein Verhalten beeinflussen; deshalb gehören Schreib- und Live-Rechte getrennt.
• Kontoverantwortung: Alle Aktionen laufen über Ihr Konto. Benachrichtigungswerkzeuge können E-Mails und SMS versenden.
• Kosten: Optimierungen und viele Backtests verbrauchen Rechenzeit; Planvoraussetzungen und Kosten prüfen Sie auf der Preisseite.
• Verantwortung: Ein Backtest ist keine Prognose. Handel mit Hebelprodukten kann zum Totalverlust führen, unabhängig davon, wie gründlich getestet wurde.

Regeln für sauberes agentisches Research.

Diese Regeln setze ich bei agentischem Strategie-Research grundsätzlich um. Sie kosten wenig Aufwand und verhindern die teuersten Fehler:

1. Hypothese und Zielkennzahl vorab festschreiben, in einer Datei im Projekt, die der Agent lesen, aber nicht ändern soll.
2. Daten dreiteilen: Entwicklung, Validierung, zurückgehaltener Test. Den Testzeitraum nennen Sie dem Agenten erst am Ende.
3. Versuchsbudget festlegen: zum Beispiel maximal 20 Backtests pro Hypothese. Alle Läufe werden gezählt und protokolliert.
4. Deflated Sharpe Ratio statt nackter Sharpe Ratio berichten, mit der tatsächlichen Zahl der Versuche.
5. Löschen und Live sperren: Deny-Regeln für Delete- und Live-Werkzeuge, Deployments nur manuell.
6. Code-Review durch einen Menschen vor jedem Paper-Trading-Start, mit Fokus auf Datenzugriff und Ordergrößen.
7. Paper zuerst, dann klein: Live-Ergebnisse mit dem Backtest im selben Zeitraum vergleichen, bevor Sie die Positionsgröße erhöhen.

Wer die Bewertung von Hypothesen weiter automatisieren will, kann einen zweiten Agenten als Prüfer einsetzen. Er bewertet Ergebnisse gegen die vorab festgelegten Kriterien, bevor ein Mensch entscheidet. Wenn Sie eine Strategie systematisch testen und anschließend sauber automatisieren lassen wollen, finden Sie mehr dazu unter Trading-Automatisierung.

Häufige Fragen.

Was ist der QuantConnect MCP-Server?

Der QuantConnect MCP-Server verbindet KI-Assistenten wie Claude über das Model Context Protocol mit der QuantConnect-API. Der Assistent kann damit Projekte und Dateien anlegen, Code kompilieren, Backtests und Optimierungen starten, Research-Notebooks ausführen und Live-Deployments steuern. QuantConnect nennt in der Ankündigung über 60 API-Endpunkte.

Brauche ich Docker für QuantConnect MCP?

Nein, nicht mehr zwingend. Stand Oktober 2026 dokumentiert QuantConnect einen Remote-Server unter www.quantconnect.com/api/v2/mcp mit Anmeldung im Browser sowie eine in VS Code eingebettete Variante. Das ältere Docker-Image quantconnect/mcp-server ist laut GitHub-Repository vorerst als veraltet markiert, funktioniert aber nach dem bisherigen Muster mit User-ID und API-Token.

Welche KI-Clients unterstützen QuantConnect MCP offiziell?

Laut QuantConnect-Dokumentation werden Claude Code, Copilot, Cursor und Devin Desktop offiziell unterstützt. Weitere MCP-fähige Clients können grundsätzlich ebenfalls funktionieren, sind aber nicht offiziell dokumentiert. Für den Remote-Server nennt die Dokumentation einen bezahlten Plan als Voraussetzung.

Kann Claude über QuantConnect MCP live handeln?

Der Server enthält Live-Werkzeuge zum Deployen, Stoppen und Liquidieren. Laut aktueller Dokumentation deployt create_live_algorithm in das Paper Trading. Für Research sollten Sie diese Werkzeuge im Client per Deny-Regel sperren und den Schritt in den Live-Betrieb selbst auslösen, zuerst im Paper Trading und mit kleiner Positionsgröße.

Wie verhindere ich Overfitting beim agentischen Backtesting?

Legen Sie Hypothese, Zielkennzahl und Datenaufteilung vorab fest, begrenzen Sie die Zahl der Backtests pro Hypothese und zählen Sie alle Versuche. Berichten Sie die Deflated Sharpe Ratio statt der einfachen Sharpe Ratio, sperren Sie das Löschen von Backtests und prüfen Sie das Ergebnis einmalig auf zurückgehaltenen Daten.

Quellen und Stand.

• QuantConnect MCP Server (Ankündigung) — QuantConnect
• MCP Server – Key Concepts — QuantConnect
• MCP Server – Claude Code — QuantConnect
• QuantConnect/mcp-server (GitHub-Repository) — QuantConnect
• Configure permissions — Anthropic (Claude Code Docs)
• The 2026-07-28 Specification — Model Context Protocol Blog
• Parameter Optimization — QuantConnect
• The Deflated Sharpe Ratio: Correcting for Selection Bias, Backtest Overfitting and Non-Normality — Bailey, López de Prado (Journal of Portfolio Management, 2014)
• LEAN CLI – Getting Started — QuantConnect (LEAN CLI Docs)

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen eine Strategie mit KI-Unterstützung sauber testen und automatisieren lassen? Unverbindlich anfragen — wir klären Hypothese, Testdesign, Rechte für KI-Agenten und den Weg ins Paper Trading. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.