Loading ToolBench
MCP memory system for AI trading agents. Store, recall, and learn from past trades.
TradeMemory has 16 tools with adequate naming conventions (verb_noun pattern present) and reasonable parameter coverage. However, critical gaps emerge: descriptions vary widely in quality (some detailed, others generic), many parameters lack type constraints (no enums for direction/strategy validation), output schemas are entirely undocumented across all tools, and error handling is missing guidance for recovery. The codebase shows FastMCP framework integration but tool definitions appear incomplete in visibility, several tools (mt5_sync, binance_sync, reflect_run_*) are only partially visible in source. Parameter descriptions often fail to explain constraints, allowed values, or dependencies. For domain-critical tools like risk_check_trade and recall_similar_trades, the output format is never specified, leaving LLMs guessing what fields to expect. Security-critical parameters (MT5 passwords, API secrets) are exposed as tool inputs rather than injected server-side. Average tool quality is C-range (fair), acceptable for internal or experimental use but not production-grade.
Poll Binance spot account trades and push to TradeMemory.
Connect to MT5 demo account.
Sync MT5 demo trades to TradeJournal.
Find past trades with similar market context. Use this before making a trade to learn from past experience. Returns trades with their reflections and outcomes. Uses OWM scoring when episodic memories exist, falls back to keyword matching.
Generate daily reflection summary.
Generate monthly reflection summary.
Generate weekly reflection summary.
No output schemas documented for any tool. LLMs cannot infer response structure, leading to incorrect field extraction and mid-chain failures. store_trade_memory, recall_similar_trades, risk_check_trade are particularly critical, their responses drive downstream decisions but formats are unspecified.
Direction parameter (long/short) and strategy_name accept free-form strings with no enum constraint. LLMs will hallucinate values like 'LONG', 'buy', 'uptrend' instead of adhering to long/short convention. No validation described.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Check if trade meets risk constraints.
Get adaptive risk constraints for trade execution.
Load agent state at session start.
Persist current state.
Store a trade decision with full context into memory. Call this after executing a trade to build your memory bank. Include market_context and reflection for better recall later.
Get current open positions with context.
Search past trades by strategy/date/result.
Log a trade decision with reasoning and context.
Log trade result after position closes.
MT5 password and Binance API keys exposed as tool parameters. These credentials appear in agent call logs, traces, and context windows. Must be injected server-side via environment or vault.
state_load and state_save accept opaque 'agent_id' and 'state' objects with minimal description. No guidance on format, size limits, or what happens on conflict. Recovery paths undefined.
No error handling guidance. Tools return failures but never explain recovery steps (e.g., 'Trade not found, try trade_query_history to locate it' or 'MT5 connection failed, verify login credentials and server name').
Pagination not implemented. trade_query_history accepts 'limit' but no offset/cursor/page mechanism. Large result sets will overflow context, LLM cannot iterate safely.
Tools like recall_similar_trades and risk_check_trade reference 'OWM scoring' and 'adaptive risk constraints' in descriptions but never explain what fields those return or what the scoring means. LLM cannot use output without reverse-engineering.
confidence parameter (0-1 float) and pnl_r (return percentage) lack value-range documentation. LLMs will guess, passing 100 for confidence instead of 1.0, or -50 for pnl_r instead of -0.5.