Locate South Korean statistical tables from a natural-language query by checking a verified catalog first, then falling back to KOSIS integrated search.
자연어로 통계표를 찾습니다. 검증된 카탈로그(통계표 ID와 분류·항목 설명)를 먼저 보고, 없으면 KOSIS 통합검색으로 넘어갑니다. 통계 조회의 첫 단계입니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 찾을 통계 주제 (예: '시도별 초등학생 수', '사교육비', '출생아 수') | |
| max_results | No | 최대 결과 수 (기본 10) | |
| include_search | No | True면 카탈로그에 결과가 있어도 KOSIS 통합검색을 함께 실행합니다 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a useful behavioral trait beyond the schema: a two-stage strategy that consults a verified catalog first and only escalates to KOSIS integrated search when nothing is found. It says nothing about result format, latency, rate limits, or whether results are cached/authoritative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose before the retrieval strategy and the 'first step' framing. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 3-parameter lookup tool with no output schema and no annotations, the description covers what it does and how it resolves queries well enough to invoke it. The main omission is any hint of what the returned catalog entries look like, which is a minor gap for a finder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented in the schema (query examples, max_results default, include_search semantics). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: finding statistical tables from natural-language queries, and positions itself as the entry point of a statistics lookup flow. It implicitly distinguishes itself from the raw KOSIS search sibling by describing a catalog-first strategy, though it never names kosis_search or kosis_list directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to reach for this tool: '통계 조회의 첫 단계입니다' (the first step of a statistics lookup) and explains the catalog-first-then-fallback ordering. It does not explicitly state when NOT to use it or which sibling to prefer for raw search, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.