Loading ToolBench
The server defines 2 tools with clear action verbs (getTechnicalData, getOhlcData) and explicit JSON schema registration. However, there are significant gaps in parameter descriptions, output documentation, and error handling guidance. Tool descriptions are present but minimal (under 100 chars). Input schemas are properly defined with type='object' and required fields, but lack parameter-level descriptions. Output schemas are referenced but not visible in the provided code, making their quality unverifiable. No evidence of error classification, recovery guidance, or idempotent operation documentation. The implementation is functional but lacks production-grade polish expected for an A-grade tool.
Gives OHLC with timestamp for the given symbol
Gives OHLC, EMA, Volume, RSI etc. indicators
Parameter descriptions missing. The 'symbol' parameter in both tools lacks a description explaining what a valid symbol format is (e.g., 'NSE stock ticker symbol, 3-5 uppercase letters').
Tool descriptions are too brief (under 100 chars). They state WHAT the tool returns but not WHEN to use it or WHY. LLMs cannot distinguish between getTechnicalData and getOhlcData based on these descriptions alone.
Output schemas not visible in source code. While mcp.Tool includes OutputSchema fields, the actual schema definitions (GetTechnicalDataOutputSchema, GetOhlcDataOutputSchema) are not shown, making it impossible to verify if output fields are documented or if they support LLM chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No error handling guidance. Functions return generic fmt.Errorf messages (e.g., 'db failure', 'schema error') without recovery steps. An LLM receiving 'db failure' has no way to know if it should retry, ask the user, or abandon the task.
No input validation error messages. Schema validation errors reference a generic 'schema error' without indicating which field or constraint was violated. LLM cannot self-correct.
No constraints on 'symbol' parameter. An LLM could pass any string (e.g., null, empty, 100 chars). No enum, regex, minLength, or maxLength defined to guide valid input.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only and idempotent but do not declare this via schema annotations, forcing LLMs to infer safety.