Loading ToolBench
Trade MCP Server with Spring AI for trading operations integration
The Trade MCP Server defines 3 tools with basic HTTP transport via Spring AI. Tool names follow verb_noun convention (generateToken, ingestInstruments, createOrder), which is positive. However, critical gaps emerge: (1) generateToken has an EMPTY input schema ({}), violating schema requirements; (2) descriptions are present but generic (10-60 chars), below the 50-200 char baseline for LLM-optimized docs; (3) ingestInstruments and createOrder have good parameter schemas with enums and type info, but lack output schema documentation; (4) parameter descriptions are minimal (e.g., 'Quantity to trade' is vague about units, limits, or expected ranges); (5) error handling and recovery guidance are not visible in the source; (6) no evidence of idempotency declarations or dry-run patterns for the IRREVERSIBLE createOrder tool. The server is functional but falls short of production-grade tool definition quality.
Create a new trading order
Generate authentication token from Groww API
Ingest instruments data from a CSV file
generateToken has an empty input schema ({}). Per HARD SCORING RULES, schema score MUST be 0. This tool accepts no documented parameters, making it impossible for an LLM to understand preconditions or how to invoke it correctly.
All tool descriptions are below 50 characters (baseline minimum for LLM optimization). generateToken: 'Generate authentication token from Groww API' (44 chars). ingestInstruments: 'Ingest instruments data from a CSV file' (39 chars). createOrder: 'Create a new trading order' (25 chars). These are too terse to guide LLM tool selection.
createOrder is marked IRREVERSIBLE (executes real trades) but has no dry-run, confirmation, or error recovery guidance. No evidence of a confirmation_request pattern or pre-execution validation step. Agents may attempt to trade without validation, risking financial loss.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Parameter descriptions lack constraint details. createOrder's 'quantity' param says 'Quantity to trade' (no min/max, no unit clarification). 'price' and 'trigger_price' lack format guidance (decimal places?). 'validity' offers no enum or documentation of valid values (e.g., DAY, IOC, GTC?).
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract return values. createOrder should document: does it return order_id, status, timestamp, execution_price? ingestInstruments should describe: success count, skipped rows, validation errors. Without documented outputs, agents cannot reason about results.
No error handling or recovery guidance visible in tool definitions. If createOrder fails (insufficient funds, invalid symbol, market closed), the LLM has no guidance on what to try next. Pattern recovery-guide absent.
ingestInstruments accepts a raw 'filepath' parameter. No guidance on file format validation, location restrictions, or path traversal prevention. Per security pattern tool-gateway, untrusted agent input must be validated and sanitized.
createOrder requires many parameters (14 total). No evidence of defaults, optional vs required distinction, or mutual exclusivity rules. An agent must reason about all combinations, increasing error risk.