realty_complex_report[유료] 단지 하나의 시세·전세·기본정보를 통합 조회한다.
응답에 좌표(latitude/longitude)와 complex_key가 들어 있다 — 이어서
realty_poi_nearby(입지)·realty_predict_price(예측)에 그대로 넣어 심층 분석하라.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 단지명 (예: 반포자이) | |
| complex_key | No | 정확한 단지 키 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, so the description only needs to add extra behavioral detail. It does by revealing response contents (coordinates, complex_key) and the paid nature of the report. This meaningfully goes beyond annotations without contradicting them.
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 very concise: a single purpose sentence plus one downstream-routing sentence. It is front-loaded with the core action and wastes no words. The paid indicator and chaining guidance both add clear value.
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?
This is a simple read-only two-parameter tool with no output schema, and the description provides enough context for the main call: what it returns, and how to use that output next. It could be slightly more explicit about whether the user must provide name or complex_key; otherwise the description is sufficiently complete for a tool of this complexity.
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?
Both parameters (name and complex_key) are already described in the schema at 100% coverage, so the baseline is 3. The description adds a bit by saying complex_key will appear in the response and can be reused downstream, but it does not clarify whether one parameter is preferred, required, or how the two relate.
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 the tool's verb and resource: it queries an integrated report for a single complex (시세, 전세, 기본정보). It conveys scope and content well, but does not explicitly distinguish it from related sibling tools like realty_complex_pyeong_price or realty_complex_rent_by_pyeong.
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?
It paints a concrete workflow: call this tool first, then feed the returned latitude/longitude and complex_key into realty_poi_nearby and realty_predict_price. That is actionable and clarifies a natural continuation. It does not explicitly mention when not to use the tool or truly contrast alternatives.
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.