realty_rental_yield[유료] 시군구별 월세 수익률·평균 매매가·평균 월세를 조회한다. 수익형 투자 스크리닝용.
기본 응답은 최신 완결월 1개월치를 수익률 내림차순으로 자른 것이다 — 전체 기간·전체
지역이 아니다(truncated 필드 확인). 특정 월은 year_month로 조회하라.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 반환 행 수 — 수익률 내림차순 상위 N (허용 범위 1~50) | |
| region | No | 시도(예: 서울특별시) 또는 시군구(예: 강남구). 세종은 시 단위로 나온다 | |
| year_month | No | YYYYMM (기본 최신 완결월) | |
| pyeong_supply | No | 분양평수 20/25/34/40/50 중 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly, idempotent, non-destructive, so the description adds essential behavioral context: the default response is a single latest completed month, sorted by descending yield, not the full period or region, and includes a truncated field to inspect. It also tells the agent to use year_month for specific months. This prevents a serious misuse of the default.
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 efficient: first line states purpose and use case, second line provides the critical behavioral caveat and the relevant parameter workaround. Every sentence earns its place with no filler.
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 no output schema, the description gives sufficient operational context: what is returned, default slicing behavior, and how to request a specific month. It lacks a short enumeration of output fields or additional details about the truncated field, but the schema covers parameters and annotations cover safety.
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 input schema already covers 100% of the four parameters, including defaults, value ranges, and examples. The description does not add much beyond what is already in the schema—it repeats year_month and the yield-descending sort. Baseline 3 is appropriate because the schema carries the parameter documentation load.
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?
Description states a specific verb and resource: '시군구별 월세 수익률·평균 매매가·평균 월세를 조회한다' and adds the use case '수익형 투자 스크리닝용'. The unique metric set (rental yield, average sale price, average rent) sets it apart from sibling realty tools even without naming them.
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 gives purpose context (investment screening) and a direct instruction for using year_month when wanting a specific month, plus clarifies that the default is truncated to one completed month. However, it does not specify when to choose this tool over the many sibling realty_* tools or when not to use it.
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.