Vor einigen Monaten habe ich meinen ersten Versuch dokumentiert: einen Crypto Trading AI Agent für Binance (Spot), gebaut mit n8n, LLMs und einer guten Portion „Vibe-Coding“. Ein erster Proof of Concept, der erstaunlich gut funktioniert hat, vor allem in bullischen Marktphasen. Sobald der Markt allerdings in eine bearishe Phase drehte, wurde es schwierig: Spot kann zwar verkaufen, aber nicht sauber „short“ gehen (und ein Long-only Setup fühlt sich in echten Drawdowns schnell wie „gegen den Markt schwimmen“ an). Genau dieser Punkt war der Auslöser für die nächste Stufe: Ein Futures AI Trading Agent.
Die wichtigste Architektur-Entscheidung dieser v2: MCP (Model Context Protocol) als Abstraktionsschicht zwischen n8n/LLM und KuCoin. Statt jede KuCoin-Integration in Workflows zu „verkleben“, laufen Trading-Aktionen über standardisierte, validierte Tools eines eigenen KuCoin Futures MCP Servers.
Jetzt, mehrere Monate später, präsentiere ich die Evolution: Ein vollständig überarbeitetes AI Trading System für KuCoin Futures. Die Unterschiede zum Vorgänger sind fundamental:
| Aspekt | Binance v1 | KuCoin v2 |
|---|---|---|
| Markt | Spot | Futures (Perpetuals) |
| API-Integration | Direkte HTTP-Calls | MCP-Server-Architektur |
| Agenten | 4 Workflows | 6 spezialisierte Workflows + 5 AI-Agenten |
| Risk Management | Basic | Confidence-basierte Sizing-Bänder |
| Order-Typen | Simple Limit/Market | Bracket Orders mit TP/SL |
| Deployment | Lokal | Vercel Edge Functions (EU) |
Im Artikel zum Binance-Trader hatte ich berichtet, dass der Bot nach ~2 Wochen Live-Betrieb bei ca. 70% Gewinnquote lag – ausdrücklich als marktabhängiges Experiment. Das war motivierend, aber eben auch: stark regimeabhängig. v2 ist mein Versuch, genau diese Regime-Fragilität zu adressieren.
In diesem Artikel nehme ich dich mit durch jeden einzelnen Workflow, erkläre das Zusammenspiel der Komponenten und zeige, wie der selbst gebaute MCP-Server als Abstraktionsschicht zur KuCoin API fungiert.
Das große Bild: Systemarchitektur
Bevor wir in die Details eintauchen, hier die Vogelperspektive. Das System besteht aus sechs n8n-Workflows, die in einer klaren Hierarchie zusammenarbeiten:
┌─────────────────────────────────────────────────────────────────┐
│ SCHEDULE TRIGGER (alle 4h) │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ ANALYST AGENT WORKFLOW │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Sentiment Agent │ │ Indicator Calc. │ │ Trading │ │
│ │ (Sub-Workflow) │ │ (Sub-Workflow) │ │ Opportunities │ │
│ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │ │
│ └────────────────────┴────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ TRADER AGENT WORKFLOW │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Trade Analyzer │ │ Executor Agent │ │ Account Agent │ │
│ │ (Sub-Workflow) │ │ (MCP Tools) │ │ (MCP Tools) │ │
│ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │ │
│ └────────────────────┴────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ MCP SERVER (Vercel EU) │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ 20 Tools: Orders, Positions, Market Data, Account Info ││
│ └─────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ KUCOIN FUTURES API │
└─────────────────────────────────────────────────────────────────┘
Der Zyklus läuft alle 4 Stunden automatisch. Vom ersten Sentiment-Signal bis zur platzierten Order vergehen typischerweise 5 – 10 Minuten – je nachdem, wie viele Symbole analysiert werden.
Workflow 1: Twitter Crypto Sentiment
Zweck: Aggregation von Crypto-Influencer-Meinungen als Echtzeit-Stimmungsbarometer
Was dieser Workflow tut
Der Twitter Crypto Sentiment Workflow ist der erste Baustein in meiner Signal-Pipeline. Er sammelt die neuesten Tweets von sechs handverlesenen Crypto-Influencern und bereitet sie für die spätere Analyse auf.
Die Influencer-Auswahl
| Account | Fokus | Warum relevant |
|---|---|---|
| Lookonchain | On-Chain-Daten | Whale-Movements, Smart Money |
| Anthony Pompliano | Macro/Bitcoin | Institutionelle Perspektive |
| Vitalik Buterin | Ethereum/Tech | Technische Entwicklungen |
| CZ (Changpeng Zhao) | Exchange/Market | Markt-Sentiment |
| Marc Andreessen | VC/Tech | Investment-Trends |
| AltcoinDaily | Altcoins | Retail-Sentiment |
Technische Umsetzung
[Execute Trigger]
→ [6 parallele HTTP Requests an twitterapi.io]
→ [6 Code Nodes: Tweet-Parsing]
→ [Merge Node: Zusammenführung]
→ [AI Agent: Sentiment-Synthese]
→ [PostgreSQL: Speicherung]
Jeder Tweet wird mit Timestamp, URL und Volltext extrahiert. Der AI Agent (GPT-5.1) fasst die Tweets dann zu einem strukturierten Report zusammen, der Narratives, Coin-Mentions und Sentiment-Tendenzen identifiziert.
Output-Format
Der Workflow produziert einen Report, der in der PostgreSQL-Tabelle cryptotwitteranalysis gespeichert wird und später vom Sentiment Analyse Agent konsumiert wird.
Workflow 2: Sentiment Analyse Agent
Zweck: Multi-Source-Fusion aller Sentiment-Daten zu einem umfassenden Market Report
Die Datenquellen
Dieser Workflow ist der Datenfusions-Hub des Systems. Er aggregiert Informationen aus fünf verschiedenen Quellen:
- CryptoCompare News API – Die 20 aktuellsten Crypto-Nachrichten
- Bitcoin On-Chain Signals – IntoTheBlock-Daten (inOutVar, addressesNetGrowth, concentrationVar, largetxsVar)
- Perplexity AI – Echtzeit-Marktanalyse mit Web-Zugriff
- Twitter Analysis – Output von Workflow 1
- Fear & Greed Index – Alternative.me API
Der AI Agent Prompt
Der Sentiment Agent hat einen umfangreichen Prompt, der ihn zu einem echten Marktanalysten macht:
## Sentiment Agent
### 0. Mission
Your mission is to **identify coins with momentum** and produce a
**comprehensive, data-driven crypto market sentiment analysis**
that another AI system can easily consume.
You must:
- Synthesize information from: News, Bitcoin on-chain signals,
Perplexity AI assessment, Twitter Sentiment, previous reports
- Output a **Markdown-formatted report in English**
- Provide **actionable insights** and a **diverse list of "Coins to Watch"**
Konsistenz durch History
Ein wichtiges Feature: Der Agent erhält seine letzten zwei eigenen Reports als Kontext. Das verhindert, dass er ständig dieselben Coins empfiehlt, und ermöglicht ihm, Veränderungen zu erkennen und zu kommentieren.
Output-Struktur
# Crypto Market Sentiment Analysis
- **ReportDate:** [ISO Date]
- **DataCutoffTimestamp:** [Timestamp]
## 1. Short-Term Market Outlook (1–7 Days)
- **OverallSentiment:** [Bullish | Bearish | Neutral | Mixed]
- **SentimentConfidence:** [High | Medium | Low]
- **KeyDrivers:** [Liste mit Quellenangaben]
- **PotentialRisks:** [Liste mit Quellenangaben]
## 2. Mid-Term Market Outlook (1–6 Months)
- **OverallSentiment:** [...]
- **KeyDevelopments:** [...]
## 3. Coins to Watch
| Coin/Token | Assessment | Reasoning & Sources | Risks/Notes |
|------------|------------|---------------------|-------------|
| ... | ... | ... | ... |
## 4. Source Coverage & Data Quality
[Metadaten über Datenverfügbarkeit]
Workflow 3: Indicator Calculator
Zweck: Multi-Timeframe technische Analyse mit klassischen Indikatoren
Warum ein eigener Workflow?
Im Binance-Projekt habe ich die Indikatoren direkt im Analyse-Agent vom LLM berechnen lassen. Das war fehleranfällig und langsam. Jetzt läuft die Berechnung in einem dedizierten Workflow, der als Tool vom Analyst Agent aufgerufen wird.
Die Indikatoren
| Indikator | Parameter | Verwendung |
|---|---|---|
| RSI | 14 Perioden (Wilder) | Überkauft/Überverkauft |
| Bollinger Bands | 20 SMA, 2σ | Volatilität, Squeeze Detection |
| MACD | 12/26/9 | Momentum, Crossovers |
| SMA | 10, 50, 200 | Trend-Identifikation |
| OBV | – | Volume Confirmation |
Multi-Timeframe-Analyse
Der Workflow holt Candle-Daten von der KuCoin Public API für vier Timeframes:
- 15m – Kurzfristige Signale
- 1h – Intraday-Trend
- 4h – Swing-Trading-Signale
- 1d – Übergeordneter Trend
Technische Umsetzung
// Auszug aus dem Indicator Calculator Code Node
const CFG = {
rsiPeriod: 14,
bbPeriod: 20,
bbStdMultiplier: 2,
macdFast: 12,
macdSlow: 26,
macdSignal: 9,
smaPeriods: [10, 50, 200],
};
// RSI (Wilder-Methode)
function rsiWilder(values, period) {
// Erste 'period' Changes für initiale Avg Gain/Loss
let avgGain = gainSum / period;
let avgLoss = lossSum / period;
// Wilder Smoothing
for (let i = period + 1; i < values.length; i++) {
avgGain = ((avgGain * (period - 1)) + gain) / period;
avgLoss = ((avgLoss * (period - 1)) + loss) / period;
out[i] = 100 - (100 / (1 + (avgGain / avgLoss)));
}
return out;
}
Output
Der Workflow gibt ein JSON-Objekt zurück, das alle Indikatoren für alle Timeframes enthält – ready to use für den Analyst Agent.
Workflow 4: Analyst Agent
Zweck: Konvertierung von Sentiment + Indikatoren in konkrete Trading-Opportunities
Der Hauptworkflow
Dies ist der Einstiegspunkt des Systems. Der Analyst Agent wird alle 4 Stunden durch einen Schedule Trigger gestartet und orchestriert die gesamte Analyse-Pipeline.
Workflow-Ablauf
[Schedule Trigger: alle 4h]
→ [Execute Sentiment Analyse Agent]
→ [Wait: 4 Minuten]
→ [Read: Sentiment from PostgreSQL]
→ [Read: Last 4 Analysis History]
→ [Merge + Prepare Data]
→ [AI Agent: Analyst]
→ [Tool: Indicator Calculator]
→ [Tool: USDTM Pair Check]
→ [Parse JSON Output]
→ [Save to PostgreSQL]
→ [Execute Trader Agent Workflow]
Der Analyst Agent Prompt
Der Analyst Agent hat einen der komplexesten Prompts im System. Er muss:
- Sentiment interpretieren und Symbole auswählen
- Indikatoren abrufen und analysieren
- Confluence Score berechnen (0-10)
- Regime klassifizieren (strong_bull, mod_bull, weak_bull, etc.)
- Präzise Entry/SL/TP Levels definieren
- Diversität sicherstellen (nicht immer dieselben Coins)
Output-Struktur
{
"asof_ms": 1750000000000,
"market_sentiment": {
"overall": "bullish",
"drivers": ["ETF inflows", "Risk-on macro"]
},
"opportunities": [
{
"symbol": "XBTUSDTM",
"bias": "LONG",
"regime": "mod_bull",
"timeframe": "4h",
"confluence_score": 7,
"confidence": 0.68,
"entry": 89701.1,
"stop_loss": 87500.0,
"take_profit_1": 92500.0,
"take_profit_2": 95000.0,
"source": { /* Detaillierte Quellenangaben */ },
"justification": [
"4h trend alignment bullish with MACD confirmation",
"RSI neutral at 52, room for upside"
]
}
]
}
Workflow 5: Trade Analyzer
Zweck: Performance-Audit und Coaching-Feedback für den Trader Agent
Warum ein Trade Analyzer?
Statt blind zu traden, analysiert das System seine eigene Performance und passt Empfehlungen an.
Die Analyse-Phasen
Der Trade Analyzer durchläuft sechs Phasen:
- PARSE & ALIGN – Letzte 6 Trading Reports parsen
- REBUILD REALITY – Fills und Positions von KuCoin holen
- KPI COMPUTATION – Win Rate, Expectancy, Drawdown berechnen
- POLICY COMPLIANCE – Regeln prüfen
- PATTERN EXTRACTION – Was funktioniert, was nicht
- CONSISTENCY CHECK – Wurden Empfehlungen befolgt?
MCP Tool Usage
Der Trade Analyzer nutzt drei MCP-Tools:
// Tools: getAccountFutures, getPositions, getFills
MCP Client → getAccountFutures("USDT")
→ getPositions()
→ getFills(symbol, start, end) // für jedes Symbol
KPIs und Metriken
| Metrik | Beschreibung |
|---|---|
win_rate |
% der Trades mit R > 0 |
avg_win_R |
Durchschnittlicher R-Multiple bei Gewinn |
avg_loss_R |
Durchschnittlicher R-Multiple bei Verlust |
expectancy_per_trade_R |
Erwartungswert pro Trade |
profit_factor |
Summe Gewinne / Summe Verluste |
max_drawdown_pct |
Maximaler Drawdown in % |
slippage_mean_pct |
Durchschnittliche Slippage |
Output: Das Briefing
Der Trade Analyzer produziert ein JSON mit strukturierten Empfehlungen:
{
"recommendations": [
{
"id": "R1",
"area": "selection",
"title": "Reduce 15m trades",
"change": "Increase min confluence from 4 to 5 for 15m",
"rationale": "15m trades have 0.2R expectancy vs 0.6R for 4h",
"priority": "high"
}
],
"consistency": {
"adherence_score": 85,
"followed_recommendations": ["Reduced venture exposure"],
"ignored_recommendations": ["Still trading PEPE"]
}
}
Workflow 6: Trader Agent
Zweck: Konvertierung von Opportunities in echte Orders via Sub-Agents
Die Agent-Hierarchie
Der Trader Agent ist der komplexeste Workflow. Er enthält drei AI Agents, die zusammenarbeiten:
┌─────────────────────────────────────────────────────────┐
│ TRADER AGENT │
│ "Plan → Select → Size → Delegate" │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ ACCOUNT AGENT │ │ EXECUTOR AGENT │ │
│ │ (o4-mini) │ │ (gpt-5.1) │ │
│ │ │ │ │ │
│ │ MCP Tools: │ │ MCP Tools: │ │
│ │ - getTicker │ │ - getSymbolDetail│ │
│ │ - getOrderBook │ │ - calculateSize │ │
│ │ - getPositions │ │ - addStopOrder │ │
│ │ - getAccountFut. │ │ - addOrder │ │
│ │ - getFundingRate │ │ - cancelOrder │ │
│ └────────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Der Trader Agent Prompt (Auszug)
## 🧠 Trader Agent — *Plan → Select → Size → Delegate*
### 0. Role & Mission
You are the **Trader Agent**.
Your responsibilities:
- Convert **Analyst Agent opportunities** + **Trade Analyzer briefing**
→ into **clean execution instructions** for the **Executor Agent**.
- You **never talk directly to exchanges**.
- You **never** change Analyst price levels.
- You **size trades using `riskPercentage`**
### 1. Invariants (must never be violated)
1. **Price levels from Analyst are sacred**
- You copy Analyst values **exactly**: entry, stop_loss, take_profit_1
2. **Monotonic checks**
- LONG: `stop_loss < entry < take_profit_1`
- SHORT: `take_profit_1 < entry < stop_loss`
3. **No tick/lot logic in Trader Agent**
- You never compute lots or round prices.
4. **Sizing only via riskPercentage**
- `riskPercentage` must be between 5 and 100.
Risk Framework
Der Trader Agent implementiert ein mehrstufiges Risk Framework:
| Regel | Limit |
|---|---|
| Aggregate Risk (neuer Zyklus) | ≤ 40% Equity |
| Per-Symbol Exposure | ≤ 40% Equity |
| Minimum Confidence | ≥ 0.45 |
| Minimum Confluence | ≥ 4 |
Confidence-basierte Sizing-Bänder
| Confidence | riskPercentage | Leverage |
|---|---|---|
| ≥ 0.65 (Strong) | 25-40% | 20-50x |
| 0.55-0.64 (Moderate) | 10-25% | 10-20x |
| < 0.55 (Weak) | 5-10% | ≤ 10x |
Der Executor Agent
Der Executor Agent ist für die tatsächliche Order-Platzierung verantwortlich. Sein Workflow:
- getSymbolDetail aufrufen → tickSize, lotSize holen
- Preise quantisieren → auf gültige Ticks runden
- calculatePositionSize aufrufen → Size aus riskPercentage berechnen
- addStopOrder aufrufen → Bracket Order platzieren
- JSON Report zurückgeben
Order-Payload Beispiel
{
"action": "addStopOrder",
"clientOid": "ta_XBTUSDTM_long_1750000000",
"symbol": "XBTUSDTM",
"side": "buy",
"type": "limit",
"price": 89701.1,
"riskPercentage": 25,
"marginMode": "ISOLATED",
"leverage": 20,
"triggerStopDownPrice": 87500.0,
"triggerStopUpPrice": 92500.0,
"stopPriceType": "MP",
"remark": "entry_tpsl_v4"
}
Der MCP Server: Das Herzstück der Integration
Warum ein eigener MCP Server?
Im Binance-Projekt habe ich direkte HTTP-Requests an die Exchange API gemacht. Das funktionierte, hatte aber Probleme:
- HMAC-Signierung musste in jedem Workflow implementiert werden
- Rate Limiting war nicht zentral gesteuert
- Error Handling war inkonsistent
Die Lösung: Ein Model Context Protocol (MCP) Server, der auf Vercel Edge Functions in Europa deployed ist.
Architektur
┌─────────────────────────────────────────────────────────────────┐
│ n8n Workflow │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ MCP Client Node ││
│ │ - Endpoint: https://remote-mcp-server... ││
│ │ - Auth: Bearer Token ││
│ │ - Tools: [addOrder, getPositions, ...] ││
│ └─────────────────────────────────────────────────────────────┘│
└────────────────────────────┬────────────────────────────────────┘
│ HTTPS + Bearer Auth
▼
┌─────────────────────────────────────────────────────────────────┐
│ MCP Server (Vercel Edge Functions) │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Authentication Layer │ │
│ │ - X-MCP-Auth-Key Header Validation │ │
│ │ - Bearer Token Support │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ JSON-RPC Handler │ │
│ │ - tools/list → Verfügbare Tools │ │
│ │ - tools/call → Tool-Ausführung │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Tool Router (20 Tools) │ │
│ │ - Input Validation (Zod Schemas) │ │
│ │ - KuCoin API Call │ │
│ │ - Response Formatting │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ KuCoin API Client │ │
│ │ - HMAC SHA256 Signature Generation │ │
│ │ - Timestamp Handling │ │
│ │ - Error Handling & Retry │ │
│ └──────────────────────────────────────────────────────────┘ │
└────────────────────────────┬────────────────────────────────────┘
│ HTTPS + HMAC Auth
▼
┌─────────────────────────────────────────────────────────────────┐
│ KuCoin Futures API │
│ https://api-futures.kucoin.com │
└─────────────────────────────────────────────────────────────────┘
Die 20 MCP Tools
Der Server bietet 20 Tools, kategorisiert nach Funktion:
Market Data (5 Tools)
| Tool | Beschreibung | Parameter |
|---|---|---|
getSymbols |
Alle verfügbaren Futures-Kontrakte | – |
getTicker |
Echtzeit-Preis und 24h-Stats | symbol |
getOrderBook |
Order Book Depth | symbol |
getKlines |
OHLCV Candle-Daten | symbol, granularity, from?, to? |
getSymbolDetail |
Contract Specs (tickSize, lotSize) | symbol |
Order Management (8 Tools)
| Tool | Beschreibung | Parameter |
|---|---|---|
addOrder |
Limit/Market Order platzieren | symbol, side, type, size, price?, … |
addStopOrder |
Bracket Order mit TP/SL | symbol, side, type, price, size, triggerStopUpPrice, triggerStopDownPrice, … |
cancelOrder |
Order stornieren | orderId oder clientOid |
cancelAllOrders |
Alle Orders stornieren | symbol? |
getOrders |
Order-Liste | status?, symbol? |
getOrderById |
Order-Details | orderId |
getOpenOrders |
Offene Orders | – |
getFills |
Ausgeführte Trades | symbol?, orderId? |
Position Management (4 Tools)
| Tool | Beschreibung | Parameter |
|---|---|---|
getPositions |
Alle offenen Positionen | – |
getPosition |
Position für Symbol | symbol |
modifyMargin |
Margin hinzufügen/entfernen | symbol, margin, bizNo |
getPositionsHistory |
Position History | symbol? |
Funding & Account (3 Tools)
| Tool | Beschreibung | Parameter |
|---|---|---|
getFundingRate |
Aktuelle Funding Rate | symbol |
getFundingHistory |
Funding History | symbol, from?, to? |
getAccountFutures |
Account Balance & Equity | currency |
Das Killer-Feature: calculatePositionSize
Ein besonders wichtiges Tool ist calculatePositionSize. Es löst eines der größten Probleme beim Futures-Trading: die korrekte Lot-Berechnung.
// Input
{
"symbol": "XBTUSDTM",
"riskPercentage": 25,
"side": "buy",
"leverage": 20,
"entryPrice": "89701.1"
}
// Output
{
"size": 15,
"marginRequired": "134.55",
"leverage": 20,
"notionalValue": "1345.52"
}
Der MCP Server kennt den multiplier, lotSize und die aktuellen Account-Balances – und berechnet daraus die korrekte Kontraktanzahl.
Deployment & Security
Der Server läuft auf Vercel Edge Functions in europäischen Regionen (Frankfurt, Dublin, Paris). Das hat zwei Vorteile:
- Latenz: Edge Functions sind schnell (<100ms Response Time)
- Geo-Bypass: Europäisches Deployment umgeht potenzielle US-Restriktionen
Die Authentifizierung erfolgt über einen Bearer Token, der in den Vercel Environment Variables gespeichert ist.
Das Zusammenspiel: Ein kompletter Trading-Zyklus
Lass mich einen kompletten Durchlauf des Systems beschreiben:
14:00 – Schedule Trigger
Der Analyst Agent Workflow startet automatisch.
14:00:05 – Sentiment Collection
- Execute Sentiment Analyse Agent
- Twitter Workflow holt Tweets von 6 Influencern
- CryptoCompare liefert News
- Perplexity AI analysiert den Markt in Echtzeit
- Fear & Greed Index wird abgerufen
- AI Agent fusioniert alles zu einem Report
- Report wird in PostgreSQL gespeichert
14:04:30 – Analyst Phase
- Sentiment Report wird gelesen
- AI Agent wählt 2-3 Symbole aus
- Für jedes Symbol: Indicator Calculator wird aufgerufen
- Confluence Scores werden berechnet
- Trading Opportunities werden generiert
- JSON wird in PostgreSQL gespeichert
14:05:00 – Trader Phase
- Trader Agent Workflow startet
- Trade Analyzer wird aufgerufen:
- Letzte 6 Reports werden gelesen
- MCP: getAccountFutures, getPositions, getFills
- KPIs werden berechnet
- Briefing wird erstellt
- Trader Agent erhält Briefing + Opportunities
- Für jede valide Opportunity:
- Account Agent prüft Exposure
- riskPercentage wird berechnet
- Executor Agent wird aufgerufen
14:05:30 – Execution Phase
Für jede Order ruft der Executor Agent nacheinander auf:
getSymbolDetail→ tickSize = 0.1- Preise quantisieren → 89701.1 ist valid
calculatePositionSize→ size = 15addStopOrder→ Order wird platziert- Response wird geloggt
14:06:00 – Reporting
- HTML Report wird generiert
- Email wird versendet
- Report wird in PostgreSQL gespeichert
- Workflow endet
Fazit
Dieses Projekt hat mich Monate gekostet – aber es hat sich gelohnt. Das System ist robuster, modularer und intelligenter als alles, was ich vorher gebaut habe.
Die Kombination aus n8n für die Orchestrierung, LangChain/OpenAI für die Intelligenz und einem eigenen MCP Server für die Exchange-Anbindung hat sich als extrem flexibel erwiesen.
Ist es perfekt? Nein. Ist es profitabel? Über die letzten Wochen hinweg: Ja! Wie es weiter läuft wird die Zeit zeigen. Aber es ist ein System, das ich verstehe, warten kann und kontinuierlich verbessere.
Ressourcen
- MCP Server Repository: github.com/mbrio089/kucoin-mcp-server
- n8n Documentation: docs.n8n.io
- KuCoin Futures API: docs.kucoin.com/futures
- Model Context Protocol: modelcontextprotocol.io
Hast du Fragen oder Feedback? Schreib mir auf LinkedIn. Die n8n Workflows teile ich gern auf Anfrage.
