realty_poi_stats[유료] 시군구별 병원·학교·지하철역 개수 통계를 조회한다. 지역 간 인프라 비교용.
지역 키는 '시도축약 시군구' 2토큰이다(예: '서울 마포구', 세종은 1토큰). 병원·지하철은
수집 범위가 수도권·광역시 중심이라 지방 시군구는 0으로 나올 수 있다 — 0을 "없다"로
단정하지 말고 수집 범위 밖일 수 있다고 말하라.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | (허용 범위 1~50) | |
| region | No | 지역명 접두 일치 (예: 서울, 서울 마포구, 마포구). 비우면 전국 전체 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses a critical behavioral nuance: coverage is limited to Seoul/metropolitan areas, so zero values may mean 'not collected' rather than 'absent'. This prevents a serious misinterpretation of the data.
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?
The description is compact and front-loaded: the core function is stated first, followed by essential formatting and data-coverage caveats. Every sentence adds value without 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?
Given there is no output schema, the description adequately describes what is returned (counts of hospitals, schools, subway stations) and the region key format. The coverage caveat prevents downstream misinterpretation, making the tool's behavior well-understood for an agent.
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?
The schema already documents both parameters, and the description adds valuable semantics for the region format: '시도축약 시군구' 2-token with a special case for Sejong. This goes beyond the schema's generic 'prefix match' description, guiding correct invocation.
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?
The description uses a specific verb ('조회한다') and a precise resource ('시군구별 병원·학교·지하철역 개수 통계'), and adds the purpose '지역 간 인프라 비교용', making it distinguishable from siblings like realty_poi_nearby or realty_region_price_stats.
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?
The description clearly states the intended use case: region-level infrastructure comparison. It does not explicitly name alternative tools or exclusion conditions, but the context is strong enough for an agent to select it when infrastructure counts are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The set has very explicit cross-tool guidance and each tool is often given a specific 'role', but there are still many overlapping clusters: auction search vs auction list vs auction detail, regional price bands vs price stats vs rankings, and court auction rate vs public auction rate. The descriptions reduce misselection, but with 51 tools including pairs like `fetch` and `realty_get_auction_case`, confusion is still likely for an agent.
Most tools follow a clean `realty_` prefix and use consistent snake_case noun-phrases or verb-noun patterns, e.g. `realty_search_auctions`, `realty_get_auction_case`, `realty_presale_cost`. The exceptions are the generic `fetch`, `search`, and `report_issue`, which break the uniform prefixed convention but are only a small minor deviation from an otherwise consistent naming system.
51 tools far exceeds the recommended threshold, even for a deliberately broad real-estate area; it is effectively an extreme number for a single MCP server. The tool count becomes the hardest usability problem, since agents must handle many tightly related micro-tools instead of interacting with a smaller, more manageable surface.
The tool set covers an impressively complete range: auction and public-auction workflows, apartment and non-apartment market, presale/cheongyak processes, tax and loan rules, subscription scoring, redevelopment, demographics, supply, POI, and even a reporting and routing tool. Boundaries and unsupported cases are explicitly documented, so there are no major obvious dead ends.