Loading ToolBench
MCP server for executing Kiwoom financial API operations, including account queries, trade execution, and realtime data streaming
The server provides 8 tools with partial schema definitions and descriptions. Most tools have basic descriptions (50-120 chars) and some parameter documentation, but fall short of production-grade quality. Naming is generally good (verb-noun pattern), but descriptions lack LLM-specific guidance, parameter descriptions are sparse, and output schemas are not formally documented. Error handling is minimal, no recovery guidance, no actionable error messages. The execute_api tool is particularly complex with many optional parameters and unclear dependencies. Overall, this is a fair C-grade effort with significant gaps in parameter validation, error handling, and schema completeness.
Execute a Kiwoom REST API request with optional automatic body construction and trade approval flow
Register for and collect realtime market data updates via WebSocket for specified items and data types
Extract API specification details (method, URL, required fields) from the Kiwoom API documentation PDF for a specific API ID
Fetch current account balance and cash holdings
Fetch deposit transaction records within a specified date range
Fetch trade execution records (buys/sells) within a specified date range
Fetch withdrawal transaction records within a specified date range
Missing output schemas for all tools. No documentation of return types, fields, structure, or downstream chaining IDs. LLMs cannot plan multi-step operations or extract required data without knowing what each tool returns.
execute_api tool has 9 parameters with complex interdependencies (question, api_id, body, path, cont_yn, next_key, max_pages, approve_trade, approval_note) but dependencies are not documented. 'question' can infer API params, but unclear when to use 'body' override vs auto-construction. Undocumented parameter relationships lead to misuse.
query_account_balance, get_api_spec have no input parameters documented (empty schema). While 'query_account_balance' may have zero required params (reasonable for a balance check), 'get_api_spec' requires 'api_id' but the schema shows only the description, not the actual parameter definition in the visible code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Search the Kiwoom REST API catalog by query, kind, major category, or minor category
No error handling guidance. Tools provide no recovery hints. When 'search_api_catalog' returns no results, there is no suggestion to broaden the query. When 'execute_api' fails with a trade API, no guidance on using approve_trade flag. LLMs cannot self-correct.
Parameter 'approve_trade' (boolean) defaults to false, which correctly blocks destructive operations. However, the error message and approval flow are embedded in tool code, not surfaced as structured guidance. The 'approval_note' parameter description is minimal ('Reason for trade approval') without explaining when it is required or what constitutes a valid reason.
Date range parameters (lookback_days) lack numeric constraints. No documented min/max. Unbounded lookback_days could cause excessive API calls or timeouts. Should specify range (e.g., 1 - 365 days).
Tool descriptions do not explain WHEN to use each tool or distinguish overlapping responsibilities. 'query_deposits', 'query_withdrawals', and 'query_trades' all fetch transaction records, the descriptions should clarify the distinction. LLMs may call the wrong tool or multiple tools when one would suffice.
execute_realtime parameter descriptions are sparse. 'trnm' ('Transaction name for realtime subscription'), 'grp_no' ('Group number'), and 'refresh' lack context on what values are valid. 'items' and 'types' are arrays but no example or constraint on array size. Timeout_seconds default (8) is mentioned but max/min not specified.
search_api_catalog 'limit' parameter has no documented upper bound. Requesting limit=10000 could retrieve excessive results. Should cap at a reasonable value (e.g., 200) and enforce pagination.
No mention of pagination support in query tools (query_deposits, query_withdrawals, query_trades). If results can exceed a threshold, LLMs need offset/limit and total_count to avoid data loss.