Loading ToolBench
A trading strategy execution system with risk management, position sizing, and trade decision automation
FriesTrader defines 7 tools with explicit schemas and descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are domain-specific and terse (avg ~80 chars), lacking LLM-optimized guidance on WHEN to call each tool or HOW to interpret results. No output schemas are documented. Error handling is minimal, tools validate inputs but provide no recovery guidance. Tool names follow verb_noun convention (conviction_trim, entry_gate, position_sizing) but lack action verbs (e.g., 'compute_conviction_trim' would be clearer). Parameters are well-typed with enums where appropriate, but descriptions often assume domain knowledge (e.g., 'per risk_rules.json/PHASE_B_TASK.md Step 5' is not actionable for an LLM unfamiliar with the codebase).
Compute conviction-trim firing for one held position, per risk_rules.json/PHASE_B_TASK.md Step 5.
Single buy/top-up gate for one candidate, combining every independent per-symbol condition that can block a buy: entry_price_gap, entry_extension, wash_sale_avoidance (buy-side guard), and the sell re-entry lock.
Compute daily/weekly P&L % against the loss-limit base and the halt decision. Daily and weekly P&L percentages are denominated against net_deposits_usd, never against total_rate_of_return.
Run Step 5's per-candidate position-sizing/risk_check math over an already priority-sorted candidate list, per risk_rules.json/PHASE_B_TASK.md. Processes candidates in order so that cash_remaining and concurrent_positions_after compound correctly.
Sort Step 5's merged new+held candidate list into priority order, per risk_rules.json/PHASE_B_TASK.md's candidate priority order: conviction tier (high before medium before low), risk_flags count ascending, pct_below_52wk_high descending.
Compute the stop-loss reference price, stop_pct, and trigger decision for one position, per risk_rules.json/PHASE_B_TASK.md Step 5. Uses sample standard deviation (ddof=1) for volatility_scaled stdev.
No output schemas documented. Tools return JSON but LLMs cannot plan downstream calls without knowing response structure. E.g., conviction_trim returns {overweight_pct, qualifies_this_cycle, consecutive_cycles, triggered, trim_dollar_amount, action} but this is inferred from code, not declared in tool metadata.
Descriptions assume deep domain knowledge (risk_rules.json, PHASE_B_TASK.md, trade_log.jsonl). LLMs cannot infer WHEN to call conviction_trim vs take_profit vs stop_loss without explicit guidance. Descriptions lack 'When to use' and 'What it returns' sections.
Tool names lack action verbs. 'conviction_trim' and 'entry_gate' are nouns/adjectives; 'compute_conviction_trim' and 'check_entry_gate' would be clearer. LLMs infer intent from verb-first names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Compute tiered take-profit firing for one position, per risk_rules.json/PHASE_B_TASK.md Step 5. Tiers are evaluated in ascending gain_pct order; a tier already fired this holding period is skipped, and a tier whose gain_pct is now met is fired against the position's quantity as it stands after any earlier tier fired in this same cycle.
Error handling is minimal. Tools validate inputs (e.g., entry_gate checks for empty daily_closes) but return generic JSON errors without recovery guidance. No distinction between retryable, user-fixable, and fatal errors.
Parameter descriptions reference external files (risk_rules.json, trade_log.jsonl) without explaining what values are valid or expected. E.g., 'loss_sale_dates' is 'comma-separated ISO dates' but no example or constraint is given.