Loading ToolBench
MCP Server for Chart Metadata Discovery. Provides tools for discovering and validating chart studies, strategies, and signals. Used by the Telegram Trading Bot to ensure robust parameter validation.
Server provides 6 read-only tools with basic descriptions and schemas. Naming follows verb_noun convention (list_*, validate_*). However, descriptions are minimal (10-50 chars for list tools), parameter descriptions are sparse, and output schemas are not formally documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint, etc.). Tools are simple discovery/validation utilities with acceptable but not production-grade quality.
Get all available bearish signal names.
Get all available bullish signal names.
Get all available trading strategy names.
Get all available chart study names.
Validate a strategy name and optionally return closest matches if invalid.
Validate a study name and optionally return closest matches if invalid.
List tools have minimal descriptions (10-50 chars). Rubric baseline is 194 chars average; descriptions under 20 chars score 0-20. These are borderline and lack context on when to call them vs. validate_* tools.
Output schemas not formally documented in code. Tools return dicts with 'studies'/'strategies'/'signals' keys and 'count', but LLMs cannot see the schema structure. Rubric requires documented return types for A+ tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared in the schema. Current MCP spec (2026-07-28) supports tool annotations for clarity.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Error handling in validate_* tools returns structured responses but lacks recovery guidance. When no match found, message says 'Use list_studies()' but does not explain why or when to call it. Rubric requires 'what to do next' in error responses.
Fuzzy matching logic (cutoff=0.5, confidence threshold=0.70) is hardcoded. No parameters to tune matching sensitivity. LLMs cannot control strictness of validation, forcing one-size-fits-all behavior.