Architektur

Diese Seite beschreibt, wie das Cryptohopper Market Data MCP intern strukturiert ist, wie Anfragen durch das System fließen und welche Garantien es hinsichtlich Datenaktualität und Verfügbarkeit gibt.

Für die konzeptionelle Einführung siehe Was ist MCP?

Komponentenübersicht

Das Cryptohopper MCP besteht aus vier Schichten:

1. Protokollschicht: Implementiert die MCP-Spezifikation — Tool-Erkennung, Aufrufe, Streaming-Antworten.
2. Auth- und Quota-Schicht: Validiert Bearer-Token, erzwingt Tier-Zugriff, zählt Aufrufe gegen wöchentliche Limits.
3. Datenaggregationsschicht: Fragt Upstream-Börsen ab, normalisiert Antworten in ein gemeinsames Schema.
4. Börsen-Konnektoren: Börsenspezifische Adapter, die zwischen nativen Börsen-APIs und dem internen Schema übersetzen.

Eine Anfrage von einem MCP-Client durchläuft alle vier Schichten in dieser Reihenfolge.

Anfrageablauf

Ein typischer Tool-Aufruf läuft wie folgt ab:

1. Client sendet Anfrage. Der MCP-Client sendet eine JSON-RPC-Anfrage über den SSE-Stream mit dem Tool-Namen und Argumenten.
2. Protokollschicht validiert. Die Anfrage wird gegen das JSON-Schema des Tools geprüft. Fehlerhafte Anfragen geben INVALID_PARAMETER oder MISSING_PARAMETER zurück.
3. Auth-Schicht validiert Token. Das Bearer-Token wird einem Konto zugeordnet. Ungültige oder widerrufene Token geben UNAUTHORIZED zurück.
4. Quota-Schicht prüft Limits. Der Aufruf wird gegen die wöchentliche Quota des Kontos und das kurzzeitige Raten-Limit gezählt. Das Überschreiten eines Limits gibt QUOTA_EXCEEDED oder RATE_LIMIT_EXCEEDED zurück.
5. Tier-Prüfung. Die angeforderte Börse und — bei Candle-Anfragen — die Lookback-Tiefe werden gegen die Erlaubnisliste des Tiers validiert. Verstöße geben EXCHANGE_NOT_SUPPORTED oder HISTORY_LIMIT_EXCEEDED zurück.
6. Aggregationsschicht leitet weiter. Die Anfrage wird an den entsprechenden Börsen-Konnektor weitergeleitet.
7. Konnektor fragt Upstream ab. Der Konnektor führt den entsprechenden Aufruf an die Upstream-Börsen-API durch.
8. Antwort normalisiert. Die Upstream-Antwort wird auf das interne Schema abgebildet und über den SSE-Stream an den Client zurückgegeben.

Jeder dieser Schritte kann die Anfrage mit einem Fehler beenden. Die Fehlersemantik wird in der Fehlerreferenz beschrieben.

Transport

Das MCP verwendet HTTP mit Server-Sent Events (SSE):

• Initiale Verbindung und Authentifizierung: eine Standard-HTTP-Anfrage.
• Fortlaufende Tool-Aufrufe: ein bidirektionaler JSON-RPC-Ablauf über SSE.

Die Wahl von SSE ist Teil der MCP-Spezifikation. Es unterstützt Streaming-Antworten und langlebige Verbindungen ohne den Overhead von speziellen Websocket-Handshakes.

Der Service-Endpunkt ist https://mcp-data.cryptohopper.com/mcp. Der gesamte Traffic ist TLS-verschlüsselt.

Zustandslosigkeit

Der MCP-Server hält keinen Session-Status zwischen Anfragen. Jeder Tool-Aufruf ist unabhängig:

• Kein serverseitiger Cursor oder Iterator.
• Kein Session-bezogener Cache.
• Kein impliziter Kontext zwischen Aufrufen.

Status, der über Aufrufe hinweg bestehen bleiben muss, liegt in der Verantwortung des Clients. In Agent-Workflows hält das Modell den Status in seinem eigenen Kontextfenster.

Datenaktualität

Jeder Datentyp hat ein unterschiedliches Aktualitätsprofil:

Datentyp	Quelle	Aktualität
Ticker	Upstream-Börse	Nahezu in Echtzeit, bei jedem Aufruf aktualisiert
Orderbuch	Upstream-Börse	Snapshot zum Anfragezeitpunkt; keine Streaming-Updates
Aktuelle Candle	Upstream-Börse	Aktueller Balken spiegelt neueste Trades wider
Historische Candle	Upstream-Börse + Cache	Unveränderlich, sobald die Candle geschlossen ist

Ticker- und Orderbuch-Aufrufe holen immer von der Upstream-Börse. Historische Candles können aus dem Cache bereitgestellt werden, wenn der Balken bereits geschlossen ist, da geschlossene Balken unveränderlich sind.

Hinweis: Das MCP bietet keinen Pub/Sub-Streaming-Modus. Jeder Aufruf ist ein Point-in-Time-Fetch.

Aggregationsmodell

Jeder Börsen-Konnektor implementiert dieselbe interne Schnittstelle, umhüllt aber die spezifische API der jeweiligen Börse. Die Aggregationsschicht:

• Normalisiert Symbolformate. Börsen verwenden unterschiedliche Paar-Notationen (BTCUSDT vs BTC-USDT vs BTC/USDT); das MCP exponiert ein einheitliches BASE/QUOTE-Format.
• Harmonisiert Feldnamen. Börsen-APIs unterscheiden sich darin, wie sie Bid-, Ask-, Last-Price- und Volumen-Felder benennen; das MCP gibt ein gemeinsames Schema zurück.
• Behandelt Zeitzonen- und Timestamp-Konventionen. Alle Timestamps in Antworten sind UTC, ISO-8601-formatiert.
• Filtert auf unterstützte Paare. Nicht-Spot-Märkte (Perpetuals, Optionen) werden von MCP-Antworten ausgeschlossen, selbst wenn die Upstream-Börse sie anbietet.

Siehe Datenmodell für das vollständige Antwortschema.

Börsenspezifische Unterschiede

Das MCP zielt auf eine einheitliche Ausgabe ab, aber Upstream-Börsenunterschiede können nicht immer vollständig verborgen werden:

• Orderbuch-Tiefe. Verschiedene Börsen exponieren unterschiedliche maximale Tiefen. Das MCP gibt zurück, was die Upstream-Börse bereitstellt.
• Candle-Zeitrahmen. Nicht jede Börse unterstützt jeden Zeitrahmen. Nicht unterstützte Kombinationen geben TIMEFRAME_NOT_SUPPORTED zurück.
• Historischer Lookback. Börsen variieren darin, wie weit zurück sie historische Daten bereitstellen. Anfragen innerhalb der Tier-Limits des MCP können dennoch fehlschlagen, wenn die Upstream-Börse diese Tiefe nicht bereitstellt; dies gibt DATA_UNAVAILABLE zurück.

Börsenspezifische Fähigkeiten spiegeln sich in der Antwort auf die Tools list-pairs und list-exchanges wider.

Upstream-Zuverlässigkeit

Upstream-Börsen-APIs können nicht verfügbar oder langsam sein. Das MCP wiederholt Upstream-Aufrufe nicht im Namen des Clients; eine fehlschlagende Upstream-Börse gibt EXCHANGE_UNAVAILABLE oder DATA_UNAVAILABLE zurück.

Von Clients wird erwartet, dass sie vorübergehende Fehler nach kurzer Verzögerung wiederholen. Gut konfigurierte MCP-Clients tun dies automatisch.

Das MCP selbst ist auf hohe Verfügbarkeit ausgelegt, hängt aber von der Gesundheit der Upstream-Börsen für die End-to-End-Zuverlässigkeit ab.

Parallelität

Mehrere gleichzeitige Tool-Aufrufe von einem einzelnen Client sind erlaubt. Jeder Aufruf ist unabhängig und zählt separat gegen die Quota. Das Raten-Limit gilt sowohl für gleichzeitige als auch für sequentielle Aufrufe.

Clients, die viele simultane Anfragen ausführen, sollten drosseln, um das Erreichen des Raten-Limits zu vermeiden.

Sicherheitsgrenze

Der MCP-Server:

• Beendet TLS am Edge.
• Validiert das Bearer-Token bei jeder Anfrage.
• Akzeptiert oder verarbeitet keine Zugangsdaten für externe Börsen. Jeder Upstream-Börsenzugriff verwendet die eigenen Zugangsdaten des MCP, die serverseitig konfiguriert sind.
• Exponiert nicht die rohen Fehlermeldungen der Upstream-Börse an den Client — Fehler werden auf die eigenen Fehlercodes des MCP abgebildet.

Clientseitige Schlüssel sind die einzigen Zugangsdaten, die Clients bereitstellen müssen. Siehe Best Practices für API-Key-Sicherheit.

Versionierung

Die MCP-Protokolloberfläche wird gemäß der MCP-Spezifikation versioniert. Tool-Schemata können sich im Laufe der Zeit entwickeln:

• Additive Änderungen (neue Tools, neue optionale Argumente, neue Antwortfelder) sind nicht-brechend.
• Brechende Änderungen (entfernte Felder, geänderte Argumenttypen) werden im Voraus angekündigt.

Clients entdecken die aktuelle Tool-Oberfläche dynamisch bei der Verbindung, sodass additive Änderungen ohne Client-Redeployment wirksam werden.