MCP-Server in Python bauen Trading-Daten für KI-Agenten.
Ein eigener MCP-Server in Python ist der sauberste Weg, Backtest-Ergebnisse, eine Kursdatenbank oder ein Positionsjournal an Claude, ChatGPT oder Codex anzubinden, ohne dem Agenten Orderrechte zu geben. Sie definieren wenige, eng zugeschnittene Werkzeuge, die nur lesen, ihre Eingaben prüfen und strukturierte Daten mit Zeitstempel zurückgeben. Stand Oktober 2026 gilt dafür die MCP-Spezifikation 2026-07-28 mit zustandslosem Protokollkern; das offizielle Python-SDK liegt in Version 2.3.0 vor, und die frühere Klasse FastMCP heißt dort MCPServer. Dieser Artikel zeigt, was sich geändert hat, wie ein minimaler Server für Backtest-Kennzahlen aussieht, wann lokal und wann remote sinnvoll ist und warum Order-Werkzeuge in einem selbst gebauten Server nichts verloren haben.
Wozu ein eigener MCP-Server für Trading-Daten?
Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen externe Werkzeuge und Datenquellen ansprechen. Der Client, etwa Claude Code, fragt den Server, welche Werkzeuge es gibt, und ruft sie bei Bedarf mit Parametern auf. Stand Oktober 2026 bieten mehrere Plattformen und Broker eigene MCP-Zugänge an, darunter TradingView (Beta), Interactive Brokers, MetaTrader 5 und cTrader. Diese Server kennen aber nur die Daten ihres Anbieters.
Die Daten, die für die eigene Entwicklungsarbeit am meisten zählen, liegen meist lokal: Backtest-Läufe aus einem Python-Framework, eine SQLite- oder Parquet-Kursdatenbank, ein Journal mit Trades, Parametern und Notizen. Ohne Schnittstelle landen diese Daten per Copy-and-paste im Chat. Das ist fehleranfällig, schnell veraltet, und niemand sieht später, welcher Datenstand zugrunde lag.
Typische Fragen, die ein Agent mit einem eigenen Server beantworten kann:
- Wie haben sich Drawdown (größter Rückgang vom Höchststand) und Profit Factor (Bruttogewinn geteilt durch Bruttoverlust) über die letzten drei Läufe einer Strategie entwickelt?
- Für welche Symbole fehlen in der Kursdatenbank Bars im letzten Monat?
- Welche Journal-Einträge der letzten Woche erwähnen Slippage oder Ausführungsprobleme?
- Unter welchen Kostenannahmen wurde ein bestimmter Lauf gerechnet?
Derselbe Server lässt sich in mehreren Clients nutzen, etwa in Claude Code, Claude Desktop und Codex (Kommandozeile und IDE); laut OpenAI teilt sich die ChatGPT-Desktop-App die MCP-Konfiguration mit Codex. Die Grundlagen des Protokolls für Unternehmen beschreibt der Artikel MCP-Protokoll im Mittelstand; hier geht es um den konkreten Bau für Trading-Daten.
Was haben die Spezifikation 2026-07-28 und das Python-SDK v2 geändert?
Die Spezifikation 2026-07-28 wurde am 28. Juli 2026 final veröffentlicht, nach einem Release Candidate vom 21. Mai 2026. Schon dessen Ankündigung im MCP-Blog nannte sie die größte Überarbeitung seit dem Start des Protokolls. Für Serverbauer sind diese Punkte relevant:
- Zustandsloser Kern: Der Handshake
initializeund protokollweite Sessions samt HeaderMcp-Session-Identfallen. Jede Anfrage trägt Protokollversion und Client-Fähigkeiten im Feld_meta. Wer Zustand über mehrere Aufrufe braucht, übergibt explizite Kennungen als normale Werkzeug-Argumente. - Neue Methode
server/discover: Server müssen darüber unterstützte Protokollversionen, Fähigkeiten und Identität ausweisen. - Erweiterungen: Tasks für lang laufende Arbeiten wurden aus dem Kern in eine offizielle Erweiterung verschoben; auch MCP Apps (vom Server mitgelieferte Oberflächen) sind als Erweiterung formalisiert.
- Autorisierung: gehärtet, unter anderem mit Prüfung des Ausstellers (
iss) nach RFC 9207. Die dynamische Client-Registrierung ist zugunsten von Client ID Metadata Documents als veraltet markiert. - Abkündigungen: Roots, Sampling und Logging gelten als veraltet und laufen nach der neuen Richtlinie mindestens zwölf Monate weiter. Protokollierung soll über
stderroder OpenTelemetry laufen.
Das offizielle Python-Paket mcp setzt das mit Version 2 um; aktuell ist 2.3.0 vom 2. Oktober 2026, vorausgesetzt wird Python 3.10 oder neuer. Die wichtigsten Unterschiede für bestehenden Code:
| Thema | SDK v1 (1.x) | SDK v2 |
|---|---|---|
| Serverklasse | from mcp.server.fastmcp import FastMCP | from mcp.server import MCPServer, ohne Kompatibilitätsschicht |
| Transport-Optionen | teils im Konstruktor | Host, Port und Transport gehören in run() |
| Attribute in Python | teils camelCase | durchgehend snake_case, etwa structured_content, is_error |
| Protokolltypen | im Hauptpaket | eigenes Paket mcp-types |
| Ältere Clients | – | ein Server bedient laut Dokumentation alte und neue Clients parallel |
Praktische Folge: Viele Anleitungen und von KI-Assistenten erzeugte Codebeispiele verwenden noch FastMCP. Pinnen Sie die Version in requirements.txt oder pyproject.toml und prüfen Sie Beispiele gegen die aktuelle SDK-Dokumentation. Die Version 1.x ist laut Dokumentation im Wartungsmodus und erhält weiter kritische Fehlerbehebungen und Sicherheitsupdates.
Welche Werkzeuge gehören in einen Trading-Daten-Server?
Ein MCP-Server ist eine Rechtevergabe. Jedes Werkzeug, das Sie anbieten, darf das Modell aufrufen, auch in einer Situation, die Sie nicht vorhergesehen haben. Deshalb gilt das Prinzip der geringsten Rechte: so wenige Werkzeuge wie möglich, jedes mit einer klar umrissenen Frage.
| Werkzeug | Zugriff | Einschätzung |
|---|---|---|
backtest_kennzahlen(strategie) | lesen | geeignet: eine Strategie, ein Ergebnis, feste Felder |
backtest_vergleich(strategie, anzahl) | lesen | geeignet, wenn anzahl nach oben begrenzt ist |
datenstand(symbol) | lesen | geeignet: letzter Bar, bekannte Lücken, Quelle |
journal(von, bis) | lesen | geeignet mit maximalem Zeitraum und gekürzten Freitextfeldern |
sql_abfrage(text) | lesen, aber offen | ungeeignet: zu breit, schwer zu kontrollieren |
parameter_setzen(...) | schreiben | nicht in diesem Server; Änderungen über Code-Review |
order_senden(...) | handeln | nie in einem selbst gebauten Daten-Server |
Drei Regeln senken das Risiko deutlich. Erstens: Ergebnisse als strukturierte Daten zurückgeben, nicht als Fließtext. Das SDK leitet aus dem Rückgabetyp, etwa einem Pydantic-Modell (Pydantic ist eine Python-Bibliothek zur Datenvalidierung), ein Ausgabeschema ab und prüft das Ergebnis dagegen, bevor es den Server verlässt. Zweitens: Jedes Ergebnis trägt seinen Datenstand mit Zeitstempel und die Annahmen, unter denen es entstanden ist, zum Beispiel das Kostenmodell. Drittens: Eingaben streng prüfen, mit festen Mustern für Kennungen, Wertebereichen für Zahlen und Obergrenzen für Zeiträume und Zeilenzahlen. Freie Dateipfade oder SQL-Texte als Parameter sind ein Einfallstor.
Die Annotation read_only_hint=True teilt dem Client mit, dass ein Werkzeug nichts verändert. Sie ist ein Hinweis, keine Sperre. Durchgesetzt wird der Schreibschutz im Server selbst: Datenbank im Nur-Lese-Modus öffnen, eigener Datenbanknutzer ohne Schreibrechte, keine Broker-Schlüssel im Prozess.
Wie sieht ein minimaler MCP-Server für Backtest-Kennzahlen aus?
Die folgende Skizze zeigt einen minimalen Server mit einem einzigen Werkzeug. Er liest den letzten Backtest einer Strategie aus einer SQLite-Datei und gibt die Kennzahlen als Pydantic-Modell zurück. Tabellen- und Spaltennamen sind Beispiele; passen Sie sie an Ihr eigenes Schema an.
# server.py – MCP-Server mit ausschließlich lesenden Werkzeugen
import sqlite3
from contextlib import closing
from typing import Annotated
from pydantic import BaseModel, Field
from mcp.server import MCPServer
from mcp.types import ToolAnnotations
DB_PATH = '/Users/ich/trading/backtests.sqlite' # absoluter Pfad
mcp = MCPServer('backtest-daten')
class BacktestKennzahlen(BaseModel):
strategie: str
zeitraum_von: str
zeitraum_bis: str
trades: int
netto_ergebnis: float = Field(description='Nach Kosten, Kontowährung')
max_drawdown_pct: float = Field(description='Maximaler Drawdown in %')
profit_factor: float | None
kostenmodell: str = Field(description='Annahmen zu Spread/Kommission')
datenstand_utc: str = Field(description='Zeitpunkt des Backtest-Laufs')
hinweis: str = 'Historischer Backtest, keine Prognose'
def verbindung() -> sqlite3.Connection:
# Datenbank nur lesend öffnen: Schutz im Code, nicht nur per Annotation
return sqlite3.connect(f'file:{DB_PATH}?mode=ro', uri=True)
@mcp.tool(
title='Backtest-Kennzahlen abrufen',
annotations=ToolAnnotations(read_only_hint=True, open_world_hint=False),
)
def backtest_kennzahlen(
strategie: Annotated[str, Field(pattern=r'^[a-z0-9_-]{1,40}$',
description='Kurzname, z. B. ema_cross_v3')],
) -> BacktestKennzahlen:
"""Kennzahlen des letzten abgeschlossenen Backtests einer Strategie."""
with closing(verbindung()) as con:
row = con.execute(
'SELECT strategie, von, bis, trades, netto, max_dd, pf, kosten, erstellt_utc '
'FROM backtests WHERE strategie = ? ORDER BY erstellt_utc DESC LIMIT 1',
(strategie,),
).fetchone()
if row is None:
raise ValueError(f'Kein Backtest für {strategie!r} vorhanden')
return BacktestKennzahlen(
strategie=row[0], zeitraum_von=row[1], zeitraum_bis=row[2], trades=row[3],
netto_ergebnis=row[4], max_drawdown_pct=row[5], profit_factor=row[6],
kostenmodell=row[7], datenstand_utc=row[8],
)
if __name__ == '__main__':
mcp.run() # ohne Argumente: stdio, lokal, kein offener NetzwerkportWas die Skizze absichtlich so macht:
- Nur-Lese-Verbindung:
mode=roverhindert Schreibzugriffe auf die Datenbank, auch wenn später jemand ein Werkzeug falsch erweitert. - Parameter statt Textbausteinen: Die Strategie geht als Platzhalter
?in die Abfrage und muss zusätzlich einem festen Muster entsprechen. - Feste Felder mit Beschreibung: Aus dem Pydantic-Modell entsteht das Ausgabeschema. Das Modell sieht Kennzahl, Einheit und Datenstand, statt eine Zahl aus Freitext zu raten.
- Kostenmodell und Hinweis im Ergebnis: Der Agent soll nicht vergessen können, dass es sich um historische Simulation unter bestimmten Annahmen handelt.
- stdio als Standard:
mcp.run()ohne Argumente startet den Server über Standard-Ein- und -Ausgabe; der Client startet ihn als lokalen Prozess.
In Claude Code registrieren Sie einen lokalen Server mit claude mcp add; alles nach -- ist der Startbefehl des Servers. Absolute Pfade machen die Konfiguration unabhängig davon, aus welchem Verzeichnis der Client den Prozess startet:
claude mcp add --transport stdio backtest-daten -- uv run --with "mcp[cli]" mcp run /Users/ich/trading/server.py
Zum Testen eignet sich der MCP Inspector, den das SDK mit uv run mcp dev server.py startet. Fehlermeldungen sollten knapp sein und keine internen Pfade oder Zugangsdaten enthalten, denn sie können im Kontext des Modells landen.
Lokal oder remote: Was gilt für Transport, Authentifizierung und Secrets?
Für einen Einzelentwickler ist der lokale Betrieb über stdio meist die richtige Wahl. Remote-Betrieb über Streamable HTTP, den HTTP-basierten Transport von MCP, lohnt sich, wenn mehrere Personen oder Web-Oberflächen von Claude und ChatGPT auf denselben Datenbestand zugreifen sollen; solche Cloud-Clients können in der Regel nur Server ansprechen, die öffentlich im Internet erreichbar sind.
| Kriterium | Lokal (stdio) | Remote (Streamable HTTP) |
|---|---|---|
| Start | Client startet den Prozess | eigener Dienst, etwa auf einem Server oder VPS |
| Authentifizierung | keine im Protokoll; Schutz über Betriebssystem-Rechte | OAuth 2.1: Server prüft bei jeder Anfrage ein Bearer-Token |
| Netzwerk | kein offener Port | TLS, Firewall, Rate-Limits nötig |
| Skalierung | nicht nötig | durch den zustandslosen Kern ohne Session-Bindung an eine Instanz |
| Aufwand | gering | deutlich höher: Betrieb, Updates, Überwachung |
Die SDK-Dokumentation formuliert die Rollenverteilung für den Remote-Fall klar: Der MCP-Server ist ein OAuth-Resource-Server. Er meldet niemanden an und stellt keine Tokens aus, sondern prüft sie. Dafür implementieren Sie einen TokenVerifier und legen die erforderlichen Scopes (Berechtigungsumfänge) fest; das SDK veröffentlicht die Metadaten nach RFC 9728, über die Clients den zuständigen Autorisierungsserver finden. Für stdio gilt dagegen: Autorisierung ist ein HTTP-Thema, der lokale Transport sieht sie nicht.
Zu Secrets gilt in beiden Fällen dasselbe: Datenbank-Zugangsdaten gehören in Umgebungsvariablen oder einen Secret-Manager, nie in den Code und nie in ein Werkzeug-Ergebnis. Broker-API-Schlüssel haben in einem Daten-Server gar nichts zu suchen. Wer Kontostände oder Positionen live braucht, nutzt den MCP-Zugang des Brokers mit dessen Rechte- und Freigabemodell.
Welche Risiken hat ein MCP-Server für Trading-Daten?
Die OWASP Top 10 for Agentic Applications 2026 führen unter anderem Agent Goal Hijack, Tool Misuse & Exploitation, Identity & Privilege Abuse und Cascading Failures als Kernrisiken. Für einen Trading-Daten-Server heißt das konkret:
- Prompt Injection: Freitext aus dem Journal, aus importierten News oder aus Dateinamen kann Anweisungen enthalten, die das Modell als Auftrag liest. Kürzen Sie Freitextfelder, kennzeichnen Sie sie als Daten und halten Sie den Server schreibfrei. Dann bleibt der mögliche Schaden auf falsche Antworten begrenzt.
- Datenabfluss: Ein Agent kombiniert Werkzeuge mehrerer Server. Positionsdaten aus Ihrem Server können so in eine Websuche oder einen anderen Connector geraten. Aktivieren Sie im Client nur die Server, die eine Aufgabe braucht, und trennen Sie Projekte mit sensiblen Daten.
- Falsche Schlüsse: Ein Sprachmodell vergleicht bereitwillig Läufe mit unterschiedlichen Kostenannahmen oder Zeiträumen und leitet daraus Aussagen ab. Ein Backtest ist eine historische Simulation, keine Prognose; überangepasste Parameter sehen im Rückblick oft gut aus. Deshalb gehören Annahmen und Datenstand in jedes Ergebnis.
- Kaskadeneffekte: Wenn ein Agent Ergebnisse weiterverarbeitet, etwa in Berichte oder Skripte, pflanzt sich ein Fehler fort. Prüfen Sie automatisch erzeugte Auswertungen, bevor Sie darauf Entscheidungen stützen.
Soll ein Agent überhaupt Orders vorbereiten, ist ein eigener Server der falsche Ort. Interactive Brokers etwa bietet einen eigenen MCP-Zugang, bei dem die KI laut Ankündigung vom 28.07.2026 nur Handelsanweisungen entwirft; der Kunde prüft jede einzeln und wandelt sie selbst auf einer IBKR-Plattform in eine Order um. Wie sich weitere Schutzschichten zwischen Modell und Konto aufbauen lassen, beschreibt der Artikel Guardrails für Trading-Agenten. Unabhängig von der Technik bleibt die Verantwortung für jede Handelsentscheidung beim Menschen; Hebelprodukte können zum Totalverlust führen.
Checkliste: MCP-Server vor dem ersten Einsatz prüfen.
Bevor Sie den Server mit echten Daten verbinden, lohnt ein kurzer Durchgang durch diese Punkte:
- SDK-Version festlegen und Beispiele auf
MCPServerstattFastMCPprüfen. - Jedes Werkzeug beantwortet genau eine Frage; kein freies SQL, keine freien Dateipfade.
- Datenbank im Nur-Lese-Modus oder mit eigenem Nutzer ohne Schreibrechte öffnen.
- Eingaben mit Mustern, Wertebereichen und Obergrenzen für Zeiträume und Zeilen validieren.
- Ergebnisse als Pydantic-Modelle mit Datenstand, Quelle und Annahmen zurückgeben.
read_only_hint=Truesetzen, aber den Schutz im Code durchsetzen.- Keine Broker-Schlüssel und keine Order-Werkzeuge im Server.
- Lokal mit stdio beginnen; remote nur mit OAuth, TLS, Rate-Limits und Protokollierung der Aufrufe.
- Mit dem MCP Inspector testen, auch mit absichtlich falschen Eingaben.
- Im Client nur die Server aktivieren, die eine Aufgabe tatsächlich braucht.
Wenn ich Trading-Systeme entwickle, trenne ich Analyse und Ausführung grundsätzlich: Werkzeuge für Auswertung und Tests liegen getrennt von allem, was ein Konto berührt. Wer seine Backtest- und Datenlandschaft so aufbereiten möchte, dass KI-Agenten sinnvoll damit arbeiten, findet unter Trading-Automatisierung den passenden Rahmen.
Häufige Fragen.
Wie baue ich einen MCP-Server in Python?
Installieren Sie das offizielle Paket mcp in Version 2, erzeugen Sie mit from mcp.server import MCPServer eine Serverinstanz und markieren Sie Funktionen mit dem Dekorator @mcp.tool(). Typ-Hinweise und Docstring werden zu Eingabeschema und Beschreibung, der Rückgabetyp zum Ausgabeschema. mcp.run() ohne Argumente startet den Server lokal über stdio. Für den Remote-Betrieb kommen Streamable HTTP und OAuth hinzu.
Was ist der Unterschied zwischen FastMCP und MCPServer?
Es handelt sich um dieselbe High-Level-Serverklasse. Mit Version 2 des offiziellen Python-SDK wurde FastMCP in MCPServer umbenannt und der Importpfad von mcp.server.fastmcp nach mcp.server verlegt, ohne Kompatibilitätsschicht. Code und Anleitungen für v1 müssen daher angepasst werden. Die Dekorator-API für Werkzeuge und Ressourcen ist weitgehend gleich geblieben.
Kann ich Claude Code über MCP auf meine Backtest-Daten zugreifen lassen?
Ja. Ein lokaler MCP-Server, der Backtest-Kennzahlen aus einer Datei oder Datenbank liest, lässt sich mit claude mcp add in Claude Code registrieren. Achten Sie auf absolute Pfade, eine Nur-Lese-Verbindung zur Datenbank und strukturierte Ergebnisse mit Datenstand. Dann kann der Agent Läufe vergleichen und Auffälligkeiten benennen, ohne Dateien oder Konten zu verändern.
Sollte ein eigener MCP-Server Orders an den Broker senden dürfen?
Davon ist abzuraten. Ein selbst gebauter Daten-Server sollte nur lesen. Sollen Orders von einem KI-Agenten vorbereitet werden, ist der offizielle MCP-Zugang des Brokers mit dessen Freigabemodell der passendere Ort. Bei Interactive Brokers etwa entwirft die KI nur Anweisungen, die der Kunde einzeln prüft und selbst als Order erfasst. So bleiben Prüfung und Verantwortung beim Menschen.
Brauche ich OAuth für einen lokalen MCP-Server?
Nein. Ein Server, der über stdio als lokaler Prozess läuft, nutzt keine Protokoll-Authentifizierung; geschützt wird er über die Rechte des Betriebssystems und der Datenbank. OAuth wird erst nötig, wenn der Server über Streamable HTTP im Netzwerk erreichbar ist. Dann prüft er als Resource-Server bei jeder Anfrage ein Bearer-Token und die nötigen Scopes.
Quellen und Stand.
- Key Changes – Specification 2026-07-28 — Model Context Protocol
- The 2026-07-28 Specification — Model Context Protocol Blog
- The 2026-07-28 MCP Specification Release Candidate (21.05.2026) — Model Context Protocol Blog
- mcp – Python SDK (Version 2.3.0, 02.10.2026) — PyPI
- What's new in v2 — MCP Python SDK Documentation
- Authorization — MCP Python SDK Documentation
- Connect Claude Code to tools via MCP — Anthropic
- OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project
- Interactive Brokers Opens AI Connectivity to Any Tool Built on the MCP Standard (28.07.2026) — Interactive Brokers
Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.
Sie wollen Ihre Backtest- und Kursdaten sicher für KI-Agenten aufbereiten? Unverbindlich anfragen — wir klären Datenquellen, Werkzeugzuschnitt und den sicheren Betrieb des Servers. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.