[유료] 지역 투자위험 분석
realty_invest_riskRead-onlyIdempotent
[유료] 지역의 투자 위험도를 변동성·유동성·공급압력 축으로 점수화한다.
응답의 disclaimer(통계 요약이며 투자 권유 아님)를 사용자에게 반드시 함께 전달하라.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 시군구명 (예: 강남구) |
korea-realty
by app.sallim
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnly, idempotent, and non-destructive. The description adds useful behavioral context: the tool is paid, and the disclaimer in the response must always be conveyed to the user. This goes beyond what annotations provide, though exact output rendering is not detailed.
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 description is short and front-loaded with the core scoring concept. It loses a little efficiency because the title already notes it is paid, and the same '[유료]' prefix is repeated in the 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 single-parameter, low-complexity, readOnly tool, the description conveys the core purpose, scoring axes, required output handling, and paid aspect. Since no output schema exists, a little more detail on response format or score interpretation would improve completeness, but it is not markedly incomplete.
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 100%, so the schema already fully documents the only parameter ('region'). The description adds no new parameter-related semantics beyond indicating that output is a regional risk score.
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 description clearly states a specific verb and resource: it 'scores' 'regional investment risk' across volatility, liquidity, and supply pressure. This distinguishes it from nearby realty tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no direct guidance on when to use this tool versus other realty analysis tools. It mentions a required user-facing disclaimer, but not conditions for selection or alternatives, leaving usage largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation3/5
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.
Naming Consistency4/5
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.
Tool Count1/5
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.
Completeness5/5
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.