← Alle Insights

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:

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:

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:

ThemaSDK v1 (1.x)SDK v2
Serverklassefrom mcp.server.fastmcp import FastMCPfrom mcp.server import MCPServer, ohne Kompatibilitätsschicht
Transport-Optionenteils im KonstruktorHost, Port und Transport gehören in run()
Attribute in Pythonteils camelCasedurchgehend snake_case, etwa structured_content, is_error
Protokolltypenim Hauptpaketeigenes 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.

WerkzeugZugriffEinschätzung
backtest_kennzahlen(strategie)lesengeeignet: eine Strategie, ein Ergebnis, feste Felder
backtest_vergleich(strategie, anzahl)lesengeeignet, wenn anzahl nach oben begrenzt ist
datenstand(symbol)lesengeeignet: letzter Bar, bekannte Lücken, Quelle
journal(von, bis)lesengeeignet mit maximalem Zeitraum und gekürzten Freitextfeldern
sql_abfrage(text)lesen, aber offenungeeignet: zu breit, schwer zu kontrollieren
parameter_setzen(...)schreibennicht in diesem Server; Änderungen über Code-Review
order_senden(...)handelnnie 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 Netzwerkport

Was die Skizze absichtlich so macht:

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.

KriteriumLokal (stdio)Remote (Streamable HTTP)
StartClient startet den Prozesseigener Dienst, etwa auf einem Server oder VPS
Authentifizierungkeine im Protokoll; Schutz über Betriebssystem-RechteOAuth 2.1: Server prüft bei jeder Anfrage ein Bearer-Token
Netzwerkkein offener PortTLS, Firewall, Rate-Limits nötig
Skalierungnicht nötigdurch den zustandslosen Kern ohne Session-Bindung an eine Instanz
Aufwandgeringdeutlich 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:

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:

  1. SDK-Version festlegen und Beispiele auf MCPServer statt FastMCP prüfen.
  2. Jedes Werkzeug beantwortet genau eine Frage; kein freies SQL, keine freien Dateipfade.
  3. Datenbank im Nur-Lese-Modus oder mit eigenem Nutzer ohne Schreibrechte öffnen.
  4. Eingaben mit Mustern, Wertebereichen und Obergrenzen für Zeiträume und Zeilen validieren.
  5. Ergebnisse als Pydantic-Modelle mit Datenstand, Quelle und Annahmen zurückgeben.
  6. read_only_hint=True setzen, aber den Schutz im Code durchsetzen.
  7. Keine Broker-Schlüssel und keine Order-Werkzeuge im Server.
  8. Lokal mit stdio beginnen; remote nur mit OAuth, TLS, Rate-Limits und Protokollierung der Aufrufe.
  9. Mit dem MCP Inspector testen, auch mit absichtlich falschen Eingaben.
  10. 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.

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.