bhardwajaditya/trader-in-broker

Was macht trader-in-broker?

Der Order-Ausführer ist die einzige Fähigkeit in diesem Paket, die zu einer echten Order führen kann, daher ist sie die strengste. Eine Order erreicht den Markt erst nach diesen Prüfungen, jedes Mal, bei jeder Order:

1. trader-in-risk hat diese exakte Order heute bestanden (abgeglichen per Fingerprint; dieselben ORDER_FIELDS und derselbe Hash wie in trader-in-risk/check.py).
2. "paper": false in trader-in/config.json. Mit Paper (Standard) wird nie etwas gesendet; Ausführungen gehen in ein lokales simuliertes Hauptbuch.
3. Der Benutzer hat explizit „yes“ für diese eine Order im Chat eingegeben.
4. Der Benutzer hat auf „Allow once“ geklickt auf Claudes eigener Berechtigungskarte für jeden place_order-Aufruf, da Order-Tools auf „Benötigt Zustimmung“ gesetzt sind.

Kein „yes“, keine Order. Ein „yes“ deckt ein Ticket (seinen Kauf und seine Stop- und Target-Legs), niemals einen Batch.

${CLAUDE_SKILL_DIR} unten ist der Ordner dieser Fähigkeit (wo diese SKILL.md lebt).

python3 "${CLAUDE_SKILL_DIR}/ticket.py" show                      # alle Tickets, READY oder nicht
python3 "${CLAUDE_SKILL_DIR}/ticket.py" approve --index 1 --reply "yes"
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper-fill --index 1 --price 1196.30           # paper: der Kauf
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper-fill --symbol RELIANCE --side sell --qty 12 --price 1212.70 --leg target
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper                     # das Paper-Hauptbuch und P&L
python3 "${CLAUDE_SKILL_DIR}/ticket.py" result --index 1 --leg entry --status placed --broker-id ID --filled-qty 12 --filled-price 1196.30
python3 "${CLAUDE_SKILL_DIR}/ticket.py" result --index 1 --leg stop --status placed --broker-id ID
python3 "${CLAUDE_SKILL_DIR}/ticket.py" fill --symbol RELIANCE --side sell --qty 12 --price 1212.70 --leg target
python3 "${CLAUDE_SKILL_DIR}/ticket.py" flatten --symbol RELIANCE --qty 12
python3 "${CLAUDE_SKILL_DIR}/ticket.py" log

ticket.py kommuniziert nie mit einem Broker. Es rendert Tickets, prüft, ob eine Antwort ein echtes „yes“ für diese Order ist, führt das Paper-Hauptbuch, erstellt das Flatten-Ticket und führt das Log in trader-in/state/broker.json. --now "2026-10-27 10:15" (oder nur 10:15) fixiert die Uhr in IST. Symbole werden akzeptiert als RELIANCE, RELIANCE.NS, NSE:RELIANCE, M&M, BSE:500325, 500325.BO.

Was es liest und schreibt

Datei	was
trader-in/orders.json	die vorgeschlagenen Orders (trader-in-budget schreibt sie; flatten ersetzt sie)
trader-in/config.json	broker (kite oder upstox), paper, product, flat_by, costs, capital_inr
trader-in/state/risk.json	die Urteile von trader-in-risk; nur ein PASS von heute ist READY
trader-in/state/broker.json	jedes yes, no, placed, leg placed und filled, mit dem max. Verlust jedes Eintrags inkl. Kosten
trader-in/state/paper.json	das Paper-Hauptbuch: Bargeld, offene Positionen, geschlossene Trades, realisierter P&L nach geschätzten Kosten
trader-in/portfolio.json	Bargeld und Aktien (Positionen geschlüsselt nach symbol wie RELIANCE.NS, mit exchange)
trader-in/plan.json	die Flat-by-Zeit für flatten
trader-in/universe.json	(Upstox) ISINs aus dem Scanner, falls vorhanden
trader-in/state/EQUITY_L.csv	(Upstox) NSEs Aktienliste, einmal heruntergeladen wenn eine ISIN benötigt wird

Ein Trade, drei Orders (lies dies vor jedem Bracket)

trader-in-budget schreibt ein „Bracket“ (Einstieg, Stop, Ziel). Zerodha und Upstox bieten keine Bracket-Orders mehr dafür an, daher wandelt das Ticket es um in:

Leg	Order	wann
1	KAUFEN, LIMIT zum Einstieg (oder MARKET), MIS oder CNC	jetzt
2	VERKAUFEN, SL-M mit trigger_price = dem Stop	erst nachdem Leg 1 gefüllt ist
3	VERKAUFEN, LIMIT zum Ziel	erst nachdem Leg 1 gefüllt ist

Legs 2 und 3 sind NICHT verknüpft (kein OCO). Wenn eine gefüllt wird, ist die andere immer noch aktiv. Storniere sie sofort, sonst kann auch sie gefüllt werden und den Benutzer short (bei MIS) oder abgelehnt (bei CNC) zurücklassen. /trader-in-alerts kann die Stop- und Zielniveaus überwachen und melden, wenn eines erreicht wird. Wenn sie vor Leg 1 platziert werden, sind Legs 2 und 3 einfache Verkaufsorders und können einen Short eröffnen.

Jedes Ticket zeigt die geschätzten Kosten (Spezifikation §6: Brokerage min(20₹, 0,03%) pro MIS-Leg, STT, Börsen- und SEBI-Gebühren, Stempelsteuer, 18% GST) und den maximalen Verlust beim Stop inklusive der Round-Trip-Kosten. Derselbe Betrag wird für das tägliche Verlustlimit von trader-in-risk protokolliert. Kosten sind immer eine Schätzung: Der Kontraktauszug enthält die tatsächlichen.

Paper (Standard)

Indische Broker haben kein Testkonto, daher ist Paper ein lokales Hauptbuch in trader-in/state/paper.json. Es wird nichts an irgendjemanden gesendet.

1. ticket.py show, ein READY-Ticket, das „yes“ des Benutzers, ticket.py approve.
2. Wenn der Preis zum Einstieg handelt, ticket.py paper-fill --index N (der Limitpreis) oder --price P. Ein Kauflimit kann nicht über seinem Limit füllen.
3. Wenn der Stop oder das Ziel handelt, erfasse diesen EINEN Verkauf: paper-fill --symbol RELIANCE --side sell --qty 12 --price 1188.10 --leg stop. Das Hauptbuch verbucht den Brutto-P&L, die geschätzten Round-Trip-Kosten und den Netto-P&L.
4. ticket.py paper gibt Bargeld, offene Positionen und realisierten P&L aus.

Der Paper-Eintrag wird als placed protokolliert (mit "paper": true), sodass trader-in-risk ihn genau wie einen Live-Eintrag gegen die Limits für Trades pro Tag und täglichen Verlust zählt.

Setup A: Zerodha Kite (offizieller MCP-Server) — Standard

Zerodhas Server ist github.com/zerodha/kite-mcp-server (MIT, Go). Überprüft gegen seine Quelle und README am 2026-10-27 (letzter Commit 5e044dc, Tag v0.4.0-dev24).

Der gehostete Server kann keine Orders platzieren. Die README sagt, der gehostete https://mcp.kite.trade/mcp „schließt potenziell destruktive Handelsoperationen aus Sicherheitsgründen aus“, und Zerodhas eigene Seiten beschreiben ihn als schreibgeschützt (ein Z-Connect-Post sagte, GTT-Orders seien die Ausnahme; der Umfang hat sich im Laufe der Zeit geändert, also überprüfe mit Claudes Tool-Liste nach dem Verbinden). Er ist kostenlos und benötigt keinen API-Schlüssel: Das login-Tool gibt einen Kite-Link zurück, der Benutzer meldet sich mit seinem eigenen Kite-Passwort und 2FA im Browser an, niemals im Chat.

Gehostet, schreibgeschützt (Kurse, Bestände, Positionen, Margen, Orders, Verlauf):

• Claude Desktop: Einstellungen > Entwickler > Config bearbeiten, den "kite"-Block aus claude_desktop_config.example.json hinzufügen (er führt npx mcp-remote https://mcp.kite.trade/mcp aus; benötigt Node.js), neustarten.
• Claude Code: claude mcp add --transport http kite https://mcp.kite.trade/mcp (oder denselben npx mcp-remote-Befehl als stdio-Server: claude mcp add kite -- npx mcp-remote https://mcp.kite.trade/mcp).

Um Orders über Claude zu platzieren, führt der Benutzer seine eigene Kopie des Servers mit seiner eigenen Kite Connect App aus:

1. Eine Kite Connect App unter developers.kite.trade erstellen (dort den aktuellen Preis prüfen). Ihre Redirect-URL muss auf den Callback des lokalen Servers zeigen; in der Serverquelle ist der Callback-Pfad /callback auf APP_HOST:APP_PORT (Standard http://localhost:8080/callback). Wir haben dies nicht Ende-zu-Ende getestet.
2. Seit dem 1. April 2026 sagen Zerodhas Support-Seiten, dass die Orderplatzierung über die API eine statische IP-Adresse benötigt, die bei Zerodha auf der Whitelist steht (NSE/SEBI Retail-Algo- Regeln). Eine Heimverbindung ohne statische IP kann zu abgelehnten Orders führen. Überprüfe Zerodhas aktuelle Regel vor dem Live-Handel.
3. Baue es: git clone https://github.com/zerodha/kite-mcp-server && cd kite-mcp-server && go build -o kite-mcp-server (Go 1.21+).
4. Füge den "kite-orders"-Block aus claude_desktop_config.example.json hinzu: den vollständigen Pfad zur Binärdatei, APP_MODE stdio, und der Benutzer trägt KITE_API_KEY und KITE_API_SECRET** selbst in diese Datei ein.**. In Claude Code: claude mcp add kite-orders -e APP_MODE=stdio -e KITE_API_KEY="$KITE_API_KEY" -e KITE_API_SECRET="$KITE_API_SECRET" -- /full/path/to/kite-mcp-servermit den Werten, die zuerst in der eigenen Shell des Benutzers exportiert wurden. Behalte nur einen vonkite/kite-orders`, wenn du beide nicht benötigst.
5. Neustarten, Claude bitten, login aufzurufen, der Benutzer öffnet den Link und meldet sich an. Kite-Sitzungen laufen täglich ab (Kite Connect Access Tokens halten bis zum nächsten Morgen), also erwarte, dich an jedem Handelstag erneut anzumelden.

Schlüssel und Tokens kommen nie in den Chat. Frage nie danach, lies die Konfigurationsdatei nicht zurück in die Konversation. Wenn der Benutzer einen Schlüssel oder Token einfügt, sage ihm, er solle diese Nachricht löschen und ihn unter developers.kite.trade neu generieren.

Tool-Berechtigungen. Anpassen > Konnektoren (Claude Desktop), den Kite-Server öffnen, setzen:

• place_order, modify_order, cancel_order, place_gtt_order, modify_gtt_order, delete_gtt_order: Benötigt Zustimmung. Niemals Immer erlauben.
• Schreibgeschützte Tools (get_profile, get_margins, get_holdings, get_positions, get_orders, get_order_history, get_order_trades, get_trades, get_gtts, get_quotes, get_ltp, get_ohlc, get_historical_data, search_instruments, login): Immer erlauben ist in Ordnung.
• In Claude Code, belasse sie auf „ask“ in .claude/settings.json: "permissions": {"ask": ["mcp__kite-orders__place_order", "mcp__kite-orders__modify_order", "mcp__kite-orders__cancel_order"]}; setze niemals ein Order-Tool auf allow. Der Server akzeptiert auch EXCLUDED_TOOLS=place_order,modify_order,cancel_order für eine schreibgeschützte Kopie.

place_order-Argumente (aus der Serverquelle): variety (regular), exchange (NSE/BSE), tradingsymbol, transaction_type (BUY/SELL), quantity (int), product (MIS/CNC), order_type (MARKET/LIMIT/SL/SL-M), price (LIMIT, SL), trigger_price (SL, SL-M), validity (DAY), optional tag (≤ 20 Zeichen; das Ticket fügt trin + 12 Hex des Fingerprints hinzu, damit die Order später gefunden werden kann). Das Tool des Servers hat kein market_protection-Argument; NSE wendet jetzt Market Protection auf API MARKET- und SL-M-Orders an, daher kann eine Market-Order vom Broker in ein geschütztes Limit umgewandelt werden. Limit-Einstiege vermeiden dies. Für BSE ist Kites tradingsymbol der Scrip-Name, nicht der numerische Code: Sieh ihn mit search_instruments nach.

Setup B: Upstox ("broker": "upstox")

• Upstoxs offizieller MCP-Server (https://mcp.upstox.com/mcp, installiert aus dem upstox/upstox-plugin-marketplace-Plugin upstox-mcp) ist schreibgeschützt: Upstoxs Seite sagt, dass du keine Orders darüber platzieren kannst. Verbindungen laufen täglich ab (OAuth-Zustimmung im Browser).
• Upstoxs offizielle Agent-Fähigkeit (/plugin install upstox-skill@upstox-plugins-official in Claude Code, nach /plugin marketplace add upstox/upstox-plugin-marketplace) kann Orders mit der v3 Order-API platzieren. Sie liest ein tägliches Access-Token aus der Umgebungsvariable UPSTOX_ACCESS_TOKEN (vom Benutzer in seiner eigenen Shell gesetzt, niemals im Chat), zeigt eine eigene Vorschau und wartet auf Bestätigung. Upstox sagt, dass es nicht im einfachen Claude Desktop-Chat läuft.
• Oder der Benutzer platziert die Order in der Upstox-App über das Ticket.

Das Ticket gibt den Body aus für POST https://api-hft.upstox.com/v3/order/place (v2 /v2/order/place ist als veraltet markiert; es nimmt dieselben Felder minus slice): quantity (int), product (I intraday = MIS, D delivery = CNC), validity DAY, price (0 für MARKET / SL-M), instrument_token, order_type, transaction_type, disclosed_quantity 0, trigger_price (0 außer bei SL / SL-M), is_amo false (Upstox ignoriert es), tag, und market_protection: -1 (automatisch) bei MARKET und SL-M, da 0 für API-Market-Orders abgelehnt wird.

instrument_token ist NSE_EQ|<ISIN> (oder BSE_EQ|<ISIN>). Die ISIN stammt aus, in der Reihenfolge: --isin, ein isin in der Order, trader-in/universe.json aus dem Scanner, sonst NSEs EQUITY_L.csv (einmal heruntergeladen mit einem Browser- User-Agent nach trader-in/state/EQUITY_L.csv, archives. dann nsearchives.). BSE-Einschränkung: Die NSE-Liste enthält nur NSE-Symbole. Ein BSE-Scrip-Code wie 500325.BO kann nicht zugeordnet werden, also übergib --isin; für ein .BO-Namenssymbol wird die ISIN der NSE-Listung verwendet (gleiches Unternehmen), aber überprüfe es. Wir haben das Upstox-Instrumentendateiformat hier nicht verifiziert. Ohne ISIN ist ein Live-Upstox-Ticket nicht READY; Paper-Tickets benötigen keine.

Schritte: der Einstieg

1. ticket.py show. Nur READY-Tickets gehen zum Benutzer. Ein Ticket, das NICHT READY oder BLOCKED ist, geht zurück zu /trader-in-risk (es hat kein Broker-JSON).
2. Zeige EIN Ticket, einschließlich der Nicht-OCO-Warnung, und frage: „Diese Order platzieren? Antworte mit yes oder no.“ Eine Order pro Frage. Biete niemals „yes to all“ an.
3. ticket.py approve --index N --reply "<die Antwort des Benutzers, wortwörtlich>". „Nicht aufgezeichnet“ bedeutet, dass die Antwort kein explizites „yes“ für diese Order war („sure“, „haan“, „yes to all“, ein „yes“, das eine andere Aktie oder Menge nennt). Frage erneut. Verwandle niemals selbst eine Antwort in ein „yes“.
4. Paper: paper-fill wie oben. Live, Kite: rufe place_order auf mit genau dem Leg-1-JSON; der Benutzer klickt auf „Allow once“. Bestätige die Ausführung (get_order_history / get_positions), dann place_order Leg 2, dann Leg 3, jeder mit eigenem „Allow once“. Live, Upstox: übergib die Bodies an die Upstox-Agent-Fähigkeit oder die App, ein Leg nach dem anderen, gleiche Reihenfolge.
5. Zeichne jedes Live-Leg auf: ticket.py result --index N --leg entry|stop|target --status placed|denied|failed --broker-id <id> (--filled-qty, --filled-price beim Einstieg). Nur der Einstieg zählt als Order für trader-in-risk; die Legs werden als leg_placed protokolliert. Eine fehlgeschlagene Order wird nicht ohne eine neue Prüfung und ein neues „yes“ wiederholt.

Schritte: während es offen ist, und raus bis flat_by

• /trader-in-alerts überwacht den Stop, das Ziel und die Flat-by-Zeit.
• Wenn der Stop oder das Ziel gefüllt wird: live, ticket.py fill ... --leg stop (es erinnert dich daran, das andere Leg jetzt zu stornieren: get_orders, dann cancel_order, benötigt Zustimmung); paper, paper-fill ... --leg stop.
• Bis flat_by (Standard 15:10 IST) wird alles noch Offene geschlossen. Broker gleichen offene MIS-Positionen automatisch etwa ab 15:20 IST aus und berechnen eine Gebühr dafür (Zerodha listet 50₹ + GST pro Order), also überlasse es nicht ihnen:
  1. Live: Frage den Broker, wie viele Aktien gehalten werden: get_positions (schreibgeschützt).
  2. ticket.py flatten --symbol RELIANCE --qty 12 schreibt einen MARKET-Verkauf (gleiches Produkt) in trader-in/orders.

[Rest gekürzt für die Übersetzung]