Loading ToolBench
Multi-server MCP ecosystem for AI-driven Korean stock analysis, market data retrieval, report generation, and cryptocurrency trading. Includes market data server, time server, SQLite database server, and ChatGPT proxy.
This MCP ecosystem exhibits significant quality gaps across definition standards. Of 13 tools, 7 have acceptable descriptions (>20 chars), but input schemas are inconsistent. Time tools (get_current_time, convert_time) and market data tools (get_stock_ohlcv, get_stock_market_cap, etc.) have properly typed parameters with descriptions, but the stock ticker parameter accepts 'string|integer' without clarification on when to use which. Database tools (read_query, write_query, create_table) expose raw SQL, which is a security concern. The append_insight tool lacks parameter descriptions. Error handling guidance is absent across all tools, no recovery hints, no actionable error messages defined. Tool names follow verb_noun convention (get_*, create_*, describe_*), which is correct, but lack of output schema documentation for any tool makes it impossible for LLMs to chain operations effectively. The ecosystem mixes financial data, time, and database operations without clear composition patterns or chaining support.
Adds a new business insight to the memo resource
Convert an ISO-8601 local datetime between IANA timezones.
Creates new tables in the database
Shows the schema for a specific table
Return the current ISO-8601 time in an IANA timezone.
Retrieves OHLCV data for a specific index.
Retrieves market capitalization data for a specific stock.
Raw SQL exposure in read_query, write_query, and create_table tools. No input validation, parameterization, or SQL injection prevention documented. This violates the security pattern and exposes the system to prompt injection attacks where LLMs are tricked into passing malicious SQL.
No output schemas documented for any of the 13 tools. LLMs cannot plan downstream operations or extract required data fields. This breaks the tool composition pattern and forces agents to guess at response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Retrieves OHLCV (Open/High/Low/Close/Volume) data for a specific stock.
Retrieves trading volume by investor type for a specific stock.
Resolves a ticker symbol to its company name.
Shows all existing tables
Executes SELECT queries to read data from the database
Executes INSERT, UPDATE, or DELETE queries to modify data
Stock ticker parameter accepts 'string|integer' without clarification. The description states '6-digit code' but does not explain when to pass as string vs integer, or whether leading zeros are preserved if integer. Ambiguous type definitions cause LLMs to misformat input.
Date parameters (fromdate, todate) accept 'string|integer' with format description 'YYYYMMDD' but no guidance on timezone handling, whether times are implied, or how daylight saving transitions are handled. Ambiguous date specifications cause off-by-one errors.
No error handling guidance for any tool. If get_stock_ohlcv fails (invalid ticker, data unavailable, API timeout), there is no documented recovery path. Agents cannot distinguish retryable from permanent failures.
append_insight has no parameter description. The input parameter 'insight' is undocumented, no guidance on length, format, structure, or whether it accepts markdown. Parameter descriptions are mandatory for LLM reasoning.
Time tools (get_current_time, convert_time) require IANA timezone names but do not document supported timezones or validation behavior if an invalid timezone is passed. Ambiguous parameter constraints cause failures.
get_stock_trading_volume has a parameter 'detail' marked as 'Unused; kept for call compatibility'. Dead parameters clutter the interface and confuse LLMs about when to set them. Remove unused parameters or document their expected behavior.
get_index_ohlcv has a parameter 'freq' marked as 'Unused; daily only'. This is a dead parameter that should be removed. Tools should not expose non-functional parameters, they add cognitive load for LLMs and invite misuse.
No pagination or result limits documented for tools returning multiple items (list_tables, read_query, describe_table). Large result sets can blow the context window. All list-returning tools must support limit and offset/cursor parameters.