Loading ToolBench
A practical MCP server implementation with multiple tools for asset pricing, weather forecasting, and website fetching
Server has 5 tools with mixed quality. Tool schemas are present and mostly well-formed (add, get_asset_price, fetch, get_alerts, get_forecast all have JSON Schema with types). However, descriptions vary significantly in quality. 'add' and 'fetch' have minimal descriptions (10-30 chars, below the 50-200 char baseline for LLM optimization). get_asset_price has excellent documentation (detailed docstring with Args/Returns). get_alerts and get_forecast have brief descriptions lacking context on when to use them. Parameter descriptions are present but inconsistent, get_asset_price documents all params well; others are sparse. No error handling guidance visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Output schemas not documented. Naming is verb-forward (get_*, add, fetch) which is good, but 'fetch' is generic, 'fetch_website' would be clearer.
Add two numbers
Fetches a website and returns its content
Get weather alerts for a US state. Args: state: Two-letter US state code (e.g. CA, NY)
Fetch historical price data from TradingView for a given asset symbol. Args: symbol (str): TradingView symbol identifier (e.g. "NASDAQ:META", "SET:BH", "BITSTAMP:BTCUSD") look_back_bars (int, optional): Number of historical bars to retrieve. Defaults to 100. time_frame (str, optional): Time interval for each bar. Valid values are "1", "3", "5", "15", "45" (minutes), "1h", "2h", "3h", "4h" (hours), "1D" (day), "1W" (week), "1M", "3M", "6M", "12M" (months). Defaults to "1D". timezone (str, optional): Timezone name as string (e.g. "America/New_York"). Defaults to "America/New_York". Returns: dict: Price data as a dictionary of records, where each record represents a price bar containing timestamp and OHLCV (Open, High, Low, Close, Volume) data.
Get weather forecast for a location. Args: latitude: Latitude of the location longitude: Longitude of the location
Minimal descriptions on 3 of 5 tools (add, fetch, get_alerts, get_forecast). 'Add two numbers' and 'Fetches a website' lack context on when to use them vs alternatives. LLMs cannot reliably select tools without 50-200 char descriptions explaining purpose and prerequisites.
No tool annotations despite all tools being READ_ONLY. FastMCP supports readOnlyHint via @mcp.tool(). Adding these annotations helps agents understand safety and retry semantics.
Output schemas not documented. get_asset_price returns dict of records (OHLCV data), documented in docstring but not in formal schema. Other tools' return types are implicit. LLMs need explicit output schemas to plan downstream calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Generic tool name 'fetch' lacks specificity. 'fetch_website' or 'fetch_webpage_content' would clarify intent. Current name could be confused with generic data fetching.
No error handling guidance. Tools lack recovery hints (e.g., 'If symbol not found, try search_symbols()' for get_asset_price). Agents cannot self-correct on failures.