Loading ToolBench
Express.js backend API for a personal trading journal application. Manages portfolios, trades, cash transactions, and analytics with Supabase database integration.
This Express HTTP server exposes 11 tools for a trading journal application. While basic CRUD operations are present, definition quality is significantly below production standards. Tool names are adequate but descriptions are minimal (avg ~50 chars vs baseline 194). Input schemas are partially visible but inconsistently documented. Most critically, tools lack parameter type definitions, descriptions are trivial, and output schemas are completely undocumented. The server shows no error handling guidance, no validation logic visible, and no awareness of the 54 Agentic Tool Patterns. Security concerns exist (portfolio operations accept bare IDs with no permission gating). Error responses in code are generic (res.sendStatus(400)) with no recovery guidance.
Creates a new portfolio with name, initial balance, and optional account type
Creates a new trade record. Requires portfolioId, pair, direction, lots, entryPrice, and date.
Deletes a portfolio and its associated trades and cash transactions
Deletes a trade record by ID
Retrieves portfolio analytics including summary statistics, equity curve, performance by pair, performance by session, and monthly performance data
Retrieves a single portfolio by ID with its associated trades and cash transactions
Retrieves all portfolios with their associated trades and cash transactions, ordered by creation date
Retrieves analytics summaries for multiple portfolios with ETag-based cache validation
Retrieves a single trade by ID
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, forcing them to parse unstructured output.
Most tool descriptions are trivial (10-35 chars). Descriptions lack WHAT the tool does, WHEN to use it, and any state-modification warnings. Descriptions should be 50-200 chars with clear actionable context.
Parameter descriptions are missing or extremely vague. 'Portfolio ID from URL parameter' is generic; should explain what a portfolio ID is and why it's needed. updateBalance and rebateBalance have no description for the increment/decrement values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Retrieves all trades or trades for a specific portfolio. Supports filtering by portfolio ID via path parameter or query parameter.
Updates a portfolio's account type and other fields. Initial balance is immutable once created.
Updates a trade record. Validates that direction is one of LONG or SHORT if provided.
No error handling guidance visible in tool definitions. Code shows generic sendStatus(400/404/500) responses with no recovery hints. Error messages should tell LLMs: can I retry? Should I ask the user? What caused this?
Destructive operations (deletePortfolio, deleteTrade) lack confirmation or dry-run support. An agent mistake could destroy trading data with no recovery path.
Tool names like 'updateBalance' and 'rebateBalance' are ambiguous. 'updateBalance' could mean set, increment, or decrement. Better names: 'incrementPortfolioBalance' and 'decrementPortfolioBalance'.
No permission gating visible. Portfolio and trade operations accept bare IDs without checking if the caller (agent) has authority. A compromised agent could access or modify any trading data.
Code shows variable name bugs (rebateBalance uses 'Trade' instead of 'Portfolio', references undefined 'updatedPortfolio'). These will cause runtime failures that break agent planning.
No input validation documented in parameter descriptions. 'balance' must be a number per code, but description doesn't state range (0 or positive?). 'portName' has no length limits documented.
getTrades has hardcoded status check but no way for agents to filter or paginate. Returning all trades for a portfolio could explode context if portfolio has hundreds of trades.