Skip to main content
Glama

Big Data Insights for Regional Inflow in Korea

estimate_life_pop

생활인구가 아직 공표되지 않은 달의 생활인구를 나우캐스트로 가늠한 '참고 추정치'를 돌려준다. 생활인구 추정 질문에는 반드시 이 도구를 쓸 것. KOSIS 표 등을 조합해 직접 계산하지 말 것.

- 이미 공표된 달이면 공표 값을 돌려준다(추정하지 않음).
- 결과의 범위는 '과거 둘 중 한 번은 이 범위 안'이라고 말할 것. '신뢰구간'·'오차범위'라고 부르지 말 것.
- 공표된 생활인구처럼 말하지 말 것. 반드시 '비공식 참고 추정치'라고 밝힐 것.
- 공표되지 않은 지역은 타지역 통근 비율 30% 미만이면 공표 지역에서 배운 공식으로 범위를 준다(등급 B, 확인 불가능한 추정).
  30% 이상(대도시 구 등)은 추정하지 않는다.
- year_month 형식: 'YYYYMM' (예: '202610').

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sido": "<sido>",
      "sigungu": "<sigungu>",
      "year_month": "<year_month>"
    },
    "name": "estimate_life_pop"
  }
}

Input Schema

NameRequiredDescriptionDefault
sidoYes
sigunguYes
year_monthYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full behavioral burden and does so unusually well: it discloses the published-vs-estimated fallback, the Grade B 'unverifiable estimate' path for low-commute regions, the hard refusal for high-commute regions (≥30%), and required disclaimer language about the range not being a confidence interval. What it omits is the shape of the returned value (fields, units, whether a range is returned as an object) and what happens on invalid region input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the mandatory-use rule are front-loaded, followed by a tight bullet list where each bullet addresses a distinct decision point (published month, range wording, disclaimer, region threshold, date format). It is slightly long and mixes calling guidance with response-phrasing instructions, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description is the only source of truth; it covers estimation caveats and refusal conditions thoroughly but leaves the region-identifier formats and the returned value's structure unexplained. For a statistical-estimation tool with three fully undocumented parameters, those gaps keep it at adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only clarifies one of three parameters: year_month format with a concrete example ('YYYYMM', e.g. '202610'). sido and sigungu get no format guidance at all — no indication whether they are Korean names, codes, or a hierarchy — which is the main ambiguity an agent would hit when calling this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource ('생활인구가 아직 공표되지 않은 달의 생활인구를 나우캐스트로 가늠한 참고 추정치를 돌려준다') and scopes it to unpublished months. It also makes the tool's unique role explicit ('생활인구 추정 질문에는 반드시 이 도구를 쓸 것'), so an agent can distinguish it from data-retrieval siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a positive trigger (any living-population estimation question), an explicit prohibition (do not hand-compute by combining KOSIS tables), and a branch for the case where the month is already published, in which it returns the published value instead of estimating. That covers when to use, when not to substitute other methods, and what happens in the edge case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources