Loading ToolBench
A LangChain-based client that connects to an MCP server to perform options trading analysis, including Greek calculations, technical indicators (RSI, EMA), and batch analysis of stock tickers.
Finance Model MCP server has 9 tools with consistent naming (all verb_noun format: get_*, calculate_*, list_*) and reasonable descriptions. However, there are significant gaps in schema completeness, parameter documentation, and output specification. All tools declare READ_ONLY risk, which is good. The main issues are: (1) output schemas are completely undocumented, we cannot see what each tool returns, forcing LLMs to guess; (2) several parameter descriptions lack detail on constraints, ranges, or formats (e.g., 'Time to expiration (in years)' does not specify valid range, precision requirements, or edge cases); (3) no parameter validation constraints (enums, min/max) are visible in schemas; (4) descriptions are brief (50-80 chars) but serviceable, though they lack context on WHEN to use each tool or dependencies between tools. The tools themselves follow good single-responsibility design (each Greek calculator is separate), and naming is clear, but the lack of output documentation is a critical gap for LLM reasoning.
Calculate the delta Greek for an option using S, K, T, r, sigma parameters
Calculate the gamma Greek for an option using S, K, T, r, sigma parameters
Calculate the rho Greek for an option using S, K, T, r, sigma parameters
Calculate the theta Greek for an option using S, K, T, r, sigma parameters
Calculate the vega Greek for an option using S, K, T, r, sigma parameters
Calculate the Exponential Moving Average (EMA) for a stock ticker
Fetch option details including S, K, T, r, and sigma parameters
Output schemas completely undocumented. No visible documentation of what each tool returns, making it impossible for LLMs to understand downstream data structure or chain tools correctly. Critical for planning multi-step agent flows.
Numeric parameters (S, K, T, r, sigma) lack constraint documentation. No min/max bounds, precision requirements, or edge case handling specified. 'Time to expiration (in years)' does not clarify if 0.01 years is valid, if it must be positive, or what happens at T=0.
Parameter 'window' for get_rsi and get_ema lacks type clarity. Described as 'window size (e.g., 14)' and 'window size (e.g., 20)' but no validation rules or range specified. LLM may pass invalid values (0, negative, >500) without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Calculate the Relative Strength Index (RSI) for a stock ticker
List available expiration dates for options on a given ticker
No error handling guidance. Tool descriptions do not explain what errors can occur (invalid ticker, missing data, API unavailable) or how the LLM should recover. A failed call leaves no clear next step.
Descriptions lack context on tool dependencies. The main.py prompt manually instructs 'use get_option_data FIRST, then calculate Greeks immediately', but this dependency is not encoded in tool descriptions. LLMs must be prompted explicitly rather than understanding it from the tool interface.
'option_type' parameter in get_option_data is described as 'Type of option (call or put)' but does not declare enum constraint. LLM could pass 'Call', 'CALL', 'call_option', or other variants without validation constraint visible.
Parameters 'period' and 'interval' for get_rsi and get_ema are documented with only examples ('6mo', '1d'). No exhaustive enum or format pattern is visible. LLM may guess at unsupported values like '3w', '4h', '30s'.