Big Data Insights for Regional Inflow in Korea

analyze_region_week

한 시군구의 한 주 관외 유입이 '평소와 다른가, 얼마나 다른가'를 판정한다.

- 평소 값: 직전 8주(연휴 주 제외) 중앙값. 비교군 대비: 같은 주 비슷한 지역 10곳의 변화를 뺀 값.
  평일 공휴일이 하루 든 주는 그 지역의 공휴일 반응을 뺀다.
- 판정은 '평소 출렁임의 몇 배'로 말할 것. 결과의 '판정' 문구는 바꾸지 말고 그대로 전할 것.
  '신뢰구간'·'유의하다'는 말은 쓰지 말 것.
- 원인(축제·날씨·행사)은 이 도구가 정하지 않는다. get_weather 등으로 판단 재료를 함께 보여 주되 단정하지 말 것.
- 판정·비교군은 이 서비스(빅데이터 Insight - 유입인구)의 비공식 계산이다. 국가데이터처 값처럼 말하지 말 것.
- sido·sigungu는 list_regions로 확인한 이름, week는 'YYYY.MM.N주차'.

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>",
      "week": "<week>"
    },
    "name": "analyze_region_week"
  }
}

Input Schema

Name	Required	Description	Default
`sido`	Yes
`week`	Yes
`sigungu`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it defines the baseline (median of the prior 8 weeks, holiday weeks excluded), the comparison adjustment (subtracting the change in 10 similar regions in the same week), and discloses that results are an unofficial in-house calculation not to be presented as official statistics. It stops short of describing error behavior for invalid region/week 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 is front-loaded in a single sentence, followed by compact bullets that each add distinct information (baseline, comparison group, output phrasing, cause disclaimer, source disclaimer, parameter formats). Density is high with little filler, though the output-phrasing rules consume disproportionate space relative to the core description.

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

Completeness4/5

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

For a statistically complex tool with no output schema and no annotations, this is close to sufficient: it explains how 'unusual' is computed, how the comparison group works, hints at a '판정' field in the result, and warns against official-statistics framing. Remaining gaps are the overall response shape and behavior on bad input.

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 coverage is 0%, so the description must compensate, and it partly does: week format is specified as 'YYYY.MM.N주차' and sido/sigungu are stated to be names verified via list_regions. It does not spell out the sido name form or what happens if a non-listed name is passed, so two of three parameters remain only partially constrained.

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

Purpose4/5

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

The opening sentence names a specific verb and resource: judging whether one district's weekly out-of-region inflow is 'unusual, and how unusual'. The scope is precise (one sido/sigungu, one week), so an agent can tell it is a single-region analysis rather than a scan, but no sibling (e.g. find_unusual_regions) is named to sharpen the contrast.

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

Usage Guidelines4/5

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

It sets clear boundaries: causes (festivals, weather) are explicitly out of scope and should be gathered via get_weather and shown as supporting evidence without asserting causation. It also constrains presentation ('신뢰구간'/'유의하다' should not be used). What is missing is when to prefer this over sibling tools such as find_unusual_regions or estimate_life_pop.

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

All Big Data Insights for Regional Inflow in Korea tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?