아파트 실거래가를 조회합니다.
Args:
district: 지역구 이름 (예: "강남구", "서초구", "성남시분당구"). 서울 25개구 + 주요 경기/광역시 지원.
year_month: 조회할 연월 (예: "202602"). YYYYMM 형식.
Returns:
해당 지역/기간의 아파트 실거래 내역 (단지명, 면적, 가격, 층, 거래일)
| Name | Required | Description | Default |
|---|---|---|---|
| district | Yes | ||
| year_month | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly explains the return payload (complex name, area, price, floor, transaction date) and the supported region scope (Seoul 25 districts + major Gyeonggi/metro). While it doesn't mention rate limits or error handling, for a read-only query tool the disclosure is adequate.
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 a clean docstring with Args and Returns sections. The purpose is the first sentence, and every sentence serves a purpose — no redundancy. It's compact and well-structured.
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 simple two-parameter query tool with an output schema, the description covers both parameters, the supported scope, and the return fields. Siblings are unrelated, so no routing confusion. Nothing essential is missing.
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 0%, so the description must fully compensate. It does: 'district' gets concrete examples (강남구, 서초구) and the supported region list, and 'year_month' gets a format example (202602) and the YYYYMM rule. This adds substantial meaning beyond the bare schema.
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 clearly states it queries apartment actual transaction prices (아파트 실거래가). It uses a specific verb (조회) and resource, and the example districts distinguish it from all siblings, which cover unrelated domains like business registration, air quality, and weather.
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 provides clear context on what inputs are needed (district and year_month) with format examples, and it's obvious from the sibling names that this is the only real-estate tool. It does not explicitly list when not to use it or alternatives, but that's unnecessary given the distinct domain.
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.