Loading ToolBench
MCP server for personal investment analysis — macroeconomics, VLCC/shipping markets
Investment MCP has 11 tools with generally present descriptions and schemas, but significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Naming is verb-first and clear (list_, get_, compare_, generate_, save_, search_), following baseline conventions. However, parameter documentation is sparse, many parameters lack detailed descriptions of format, constraints, and dependencies. Output schemas are not documented at all, forcing LLMs to infer result structure. Error handling returns generic messages without recovery guidance. The server implements basic financial data retrieval patterns well, but lacks the rigor expected of production agent tools. Average per-tool score: 52 (ranging 35 - 68). STDIO transport caps protocol readiness at 50.
Get normalized comparison data for multiple instruments over the same time range.
Generate a full overview dashboard with all tracked instruments.
Generate an interactive HTML report with Plotly charts for selected instruments.
Fetch historical time series data for a financial instrument. Returns date and value columns.
Retrieve a financial analysis knowledge file for context. Topics: vlcc_analysis, macro_indicators, shipping_market, yield_curve_analysis, tanker_company_profiles
Get the most recent data point for a financial instrument.
Missing output schemas for all 11 tools. LLMs cannot plan downstream operations without knowing response structure. E.g., get_historical_data and compare_instruments describe returning 'data' but don't specify fields (date format, value column name, array vs object).
Parameter descriptions lack format constraints and validation rules. Date parameters (start_date, end_date) mention 'YYYY-MM-DD format' only in description text, not in JSON Schema 'pattern' fields. Instrument_id format is shown via examples (fred:DGS10, stock:FRO, shipping:BDI) but not formally constrained.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
List all available financial instruments with metadata. Optionally filter by category (macro, stock, shipping).
List all available financial analysis knowledge files.
List all saved analysis notes with dates, titles, and tags.
Save a conversation summary or analysis note as a markdown file.
Full-text search through saved analysis notes.
Enumerated values provided as inline examples in descriptions instead of JSON Schema enums. get_knowledge lists topics (vlcc_analysis, macro_indicators, etc.) as examples; should be declared as enum in schema.
No error recovery guidance. Error messages in code (e.g., 'Instrument not found', 'No data available') do not suggest next steps or available alternatives. Per pattern:recovery-guide, errors should guide LLM toward resolution.
WRITE operations (generate_report, generate_dashboard, save_note) lack confirmation or dry-run support. Agents may inadvertently generate large reports or overwrite notes without explicit approval.
No pagination or result limiting for list-type tools and search. list_instruments, list_knowledge, list_notes, and search_notes lack limit/offset parameters and total count documentation. Per pattern:paginated-result, large result sets can exhaust context windows.
Tool descriptions are inconsistent in length and detail. generate_dashboard description is ~60 chars (too brief to guide LLM selection); others like get_historical_data are ~150 chars (good). Baseline is 10 - 1024 chars, p50~194 chars. Five tools fall below p10 (34 chars).
No documentation of chaining IDs. If search_notes returns matching notes, do responses include note_id so subsequent get_note (if it existed) could be called? Responses not documented, so composition risk is high.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). These help LLMs reason about safety and retry logic. Currently only Risk field in metadata, not visible in schema.