PFT Edgebook - Trading Journal

All trades carrying a given tag/setup name (any tag category) plus aggregate stats for that setup. `stats` uses exactly the definitions of get_stats: counted trades only (closed, with a P&L), every money figure net of fees per trade, break-even trades NOT in the win-rate denominator, one profit factor (net wins ÷ |net losses|, null without losses), and `not_counted` = matching trades left out because they are open or have no result. Each trade carries `strategies` as a LIST, not a single value: a trade can belong to several of the trader's strategies. An empty list normally means it belongs to none — but ONLY if the response does not also carry `strategies_incomplete`; when it does, an empty list means unknown, and you must not say the trade is unassigned. The per-strategy figures from get_stats are built from the same assignment, so the two agree. FIELD MEANINGS (the names are misleading): `max_up_move` is the MFE — how far the trade ran IN FAVOUR of the position while open (LONG: high - entry, SHORT: entry - LOW). It does NOT mean "the price went up": on a short a big positive value means the market FELL, which was good. `max_down_move` is the MAE, the move AGAINST the position, normally negative. A negative max_up_move means the trade was never in profit. `post_exit_mfe`/`post_exit_mae` are the same after the exit (use for "exited too early/late", never for the result). All four are PRICE POINTS, not currency. `r_multiple` is the result as a multiple of the risked amount. `trade_high`/`trade_low` are real price levels — the favourable one is trade_high for a long, trade_low for a short. A null value means the trade came from a source without a live connection.

analyze_setup

The trader's per-day notes, merged by date: the free-form reflection PLUS the trade-tab day — pre-market plan, intraday journal and voice note. Everything the trader writes around a trading day. Optional ISO date range. Days may also carry `key_levels`, `hypotheses` and `custom_sections` ([{title, text}]) — the trader's own sections from their note template, in template order; read them like the rest of the day's notes.

get_journal

The trader's trading accounts: id, name, type, broker, realized P&L from the journalled trades and trade count. `id` is the exact account id — pass it as `account_id` to get_stats/get_trades instead of guessing a name substring. `type` is the trader's own classification, one of "prop" (prop-firm account), "live" (own broker account) or "demo" (simulation/paper). It does NOT by itself prove whether a figure is real money: a prop-firm EVALUATION is traded on a simulated account, and replay or backtest trades may sit on an ordinary account under any type (they are usually recognisable only by the account NAME). If the difference matters for the answer, name the accounts you used and ask the trader rather than assuming. Balances are deliberately NOT available — they are never synced to the cloud. Account numbers and digits inside names are masked: only the last 3 characters are real (e.g. "****567"). Use them to tell accounts apart; never report them as corrupted and never reconstruct them.

get_accounts

List journal trades with optional filters (time range ISO, instrument root e.g. "MNQ", direction long/short). Newest first. Each trade carries `strategies` as a LIST, not a single value: a trade can belong to several of the trader's strategies. An empty list normally means it belongs to none — but ONLY if the response does not also carry `strategies_incomplete`; when it does, an empty list means unknown, and you must not say the trade is unassigned. The per-strategy figures from get_stats are built from the same assignment, so the two agree. FIELD MEANINGS (the names are misleading): `max_up_move` is the MFE — how far the trade ran IN FAVOUR of the position while open (LONG: high - entry, SHORT: entry - LOW). It does NOT mean "the price went up": on a short a big positive value means the market FELL, which was good. `max_down_move` is the MAE, the move AGAINST the position, normally negative. A negative max_up_move means the trade was never in profit. `post_exit_mfe`/`post_exit_mae` are the same after the exit (use for "exited too early/late", never for the result). All four are PRICE POINTS, not currency. `r_multiple` is the result as a multiple of the risked amount. `trade_high`/`trade_low` are real price levels — the favourable one is trade_high for a long, trade_low for a short. A null value means the trade came from a source without a live connection.

get_trades

Aggregate performance (win rate, net P&L, avg win/loss, profit factor, avg R) over an optional time range / instrument / account / strategy. SCOPE — READ BEFORE QUOTING ANY NUMBER: without an account filter this aggregates EVERY account the trader has, including demo, simulation, replay and backtest accounts, in ONE figure. A profit factor or P&L mixed across real and simulated trading looks like a genuine number and is not one. Call get_accounts first, then either filter by `account_id` or state explicitly which accounts the figure covers. Never present an unfiltered figure as the trader's real-money performance. DEFINITIONS (identical to the trader's dashboard): only COUNTED trades enter any figure — a trade counts when it is closed AND has a P&L; open trades and trades without a result are only reported in `not_counted`. `gross_pnl` is the sum of P&L before fees; `net_pnl` = gross_pnl − total_fees. EVERY other money figure is NET per trade (P&L − fees): `avg_win`, `avg_loss` (negative), `best`, `worst`, `expectancy`, `profit_factor`. A trade is a win if its net is above 0, a loss if below 0, and BREAK-EVEN if its net is exactly 0 to the cent (+$2 gross with $4 fees is a LOSS). `win_rate_pct` = wins ÷ (wins + losses): break-even trades are NOT in the denominator (null when there is no win and no loss). `profit_factor` = sum of net wins ÷ |sum of net losses| (null when there is no loss — say "no losing trades", never "infinite" or 0). `expectancy` = net_pnl ÷ trades (break-even counts). `payoff_ratio` = avg_win ÷ |avg_loss|. `avg_r_multiple` is the PLAIN arithmetic mean of `r_multiple` over only those trades that actually carry one; trades without a recorded risk are dropped from both numerator and denominator, so its sample is usually SMALLER than `trades` and it is not weighted by size, P&L or duration (null when no trade has an R — never describe it as 0 or as an average over all trades). `trading_days` = number of distinct calendar days on which a counted trade was ENTERED; `green_days` = days whose net sum is above 0 (a swing trade belongs to its entry day). Days are cut in the trader's own time zone, named in `tag_zeitzone` ("UTC" means the trader has not set one yet, so late-evening/night trades may sit on the neighbouring day). A null value means "no data", never zero. Use `strategy` together with get_playbook to answer "how is this strategy performing" — it aggregates over every trade assigned to that strategy, including trades assigned afterwards. If the result contains `error: "stats_incomplete"` instead of numbers, say so and do not substitute the overall figures.

get_stats

The trader's own definitions: strategies, setups and trading rules (each with the trader's own description of what it means), plus setup criteria. Use this to understand what the trader INTENDS, then compare against the actual trades (which reference these by name). A `description` of null means the trader wrote none — do not invent one and do not read the name as a definition.

get_playbook

The trader's prop-firm challenge/funded accounts: firm, phase, status, the rule set (drawdown/target/daily-loss/consistency), the linked trading account, and the transaction history (fees/payouts by kind, category and date). Use to assess how the trader stands in their prop challenges. Account SIZE (starting balance) is deliberately not available — it is never synced to the cloud. The rules are RELATIVE: `…Pct` fields are fractions of the account size (`profitTargetPct: 0.06` = 6%), never dollar amounts. Transaction sums are omitted for the same reason. Reason in percentages; never multiply the fractions out and never estimate the account size.

get_prop_accounts

Full-text search across trade notes and daily journal entries.

search_notes

Detail for one trade. Use `detail` to control the response size (default "summary" = core trade fields only, no bars/images). Ask for larger levels only when needed: "execution" adds fills, MFE/MAE and stop/target; "chart_data" adds OHLC bars; "screenshots" adds up to 4 chart images; "full" returns everything. Each trade carries `strategies` as a LIST, not a single value: a trade can belong to several of the trader's strategies. An empty list normally means it belongs to none — but ONLY if the response does not also carry `strategies_incomplete`; when it does, an empty list means unknown, and you must not say the trade is unassigned. The per-strategy figures from get_stats are built from the same assignment, so the two agree. FIELD MEANINGS (the names are misleading): `max_up_move` is the MFE — how far the trade ran IN FAVOUR of the position while open (LONG: high - entry, SHORT: entry - LOW). It does NOT mean "the price went up": on a short a big positive value means the market FELL, which was good. `max_down_move` is the MAE, the move AGAINST the position, normally negative. A negative max_up_move means the trade was never in profit. `post_exit_mfe`/`post_exit_mae` are the same after the exit (use for "exited too early/late", never for the result). All four are PRICE POINTS, not currency. `r_multiple` is the result as a multiple of the risked amount. `trade_high`/`trade_low` are real price levels — the favourable one is trade_high for a long, trade_low for a short. A null value means the trade came from a source without a live connection.

get_trade_detail