MCP server providing Korean stock market data from data.go.kr APIs, including stock prices, market indices, dividends, and stock listings
The server provides 3 well-named tools with mostly complete parameter schemas and descriptions in Korean. Tool naming is clear and action-oriented (get_stock_price, search_stock, get_market_index). Parameter descriptions are present and detailed. However, there are significant gaps: (1) output schemas are not formally documented, responses are formatted as free-text strings rather than structured JSON objects, making it impossible for LLMs to extract and chain data; (2) parameter descriptions lack explicit enum constraints (market values like 'KOSPI', 'KOSDAQ', 'KONEX' are mentioned but not formalized as enums in the schema); (3) error handling is minimal, most error cases return plain-text error messages without guidance on recovery or alternatives; (4) no documented pagination behavior despite num_results parameters; (5) response fields are not guaranteed to match parameter names (e.g., 'mrktCtg' in response vs 'market' in input).
KOSPI, KOSDAQ 등 주요 시장 지수를 조회합니다.
한국 주식 시세를 조회합니다. 종목명 또는 종목코드로 검색할 수 있습니다. 데이터는 전일 종가 기준입니다 (당일 실시간 아님).
종목명 키워드로 KRX 상장종목을 검색합니다.
Output schema not documented, tools return plain-text string responses instead of structured JSON with typed fields. This violates the response-shaper pattern and forces LLMs to parse unstructured text, increasing errors and wasting tokens.
Enum constraints not formalized in schema. The 'market' parameter description mentions KOSPI, KOSDAQ, KONEX as examples, but the parameter type is a plain string. No enum constraint in the JSON Schema means LLMs may pass invalid values like 'kospi' (lowercase) or 'STOCK_MARKET' (hallucinated). Should use JSON Schema enum field.
Parameter descriptions contain example values (e.g., '예: "삼성전자", "NAVER"') which LLMs tend to reuse literally in subsequent calls, causing hallucination. Should move examples to separate enum or pattern constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
Error handling is generic and non-actionable. Errors return plain strings like 'API 오류: ...' or 'HTTP 200: ...' without suggesting recovery steps. Per pattern:recovery-guide, errors should indicate whether the call is retryable, what the user should correct, or when to try alternative tools.
Pagination not clearly documented. Tools accept 'num_results' but do not return a total_count, next_cursor, or page_number in the response schema. Cannot verify whether pagination is supported or how to iterate over large result sets.
Response field names do not consistently match input parameter names. Input param 'market' maps to response field 'mrktCtg'; input 'stock_code' maps to output 'likeSrtnCd' or unlabeled. This forces LLMs to reason about field mappings, increasing errors per pattern:mxe:response-field-naming.
No documented return type. The tool docstring says it returns '종가, 시가, 고가, 저가, 거래량, 등락률, 시가총액 등' (close, open, high, low, volume, change rate, market cap, etc.) but does not formally specify the JSON structure. LLMs cannot plan downstream operations without knowing exact field names and types.