Skip to main content
Glama

korea-realty

by app.sallim

거시 지표 (기준금리·KOSPI·M2 시계열)

realty_macro_indicators
Read-onlyIdempotent

한국 기준금리·KOSPI·M2, 미 연준금리·S&P500 등 거시 지표의 월별 시계열을 조회한다. "금리가 집값에 어떤 영향?"류 배경 분석용.

⚠️ 계열마다 신선도가 다르다 — meta.series_as_of가 계열별 실제 최신 시점이다(예: 미
연준금리·S&P·코인은 최신인데 한국 기준금리·KOSPI는 2024-12 정지, ECOS 재수집 대기).
밀린 계열을 "지금 금리"로 인용하지 말고 반드시 그 계열의 시점을 함께 밝혀라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
monthsNo최근 몇 개월치 (허용 범위 1~240)
indicatorsNo쉼표 구분 지표명: bok_base_rate(한국 기준금리 %), kospi(월말 종가), korea_m2(M2 평잔·원계열, 조원), fed_rate(미 연준금리 월평균 %), us_m2(미 M2 계절조정 $B), sp500, btc_usd, eth_usd(월말 종가). 비우면 전체. 목록에 없는 이름은 거절한다(조용히 버리지 않는다)

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds crucial behavioral context beyond annotations: series freshness varies per series and must be checked via meta.series_as_of; stale series (Korea base rate, KOSPI) are not 'current' and should not be cited as such; invalid indicator names are rejected rather than silently dropped. This explains what the tool does beyond simple reads and is important for accurate interpretation of results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-paced: two sentences of purpose, one hint about usage, one caveat paragraph about freshness. The most important practical caveat (series_as_of) appears at the end, but the warning is short and not buried. Every sentence earns its place, no redundancy.

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?

The key gap is the series_as_of metadata being important and not part of a structured output schema (no output schema present). The description does a good job giving the specific context of what to inspect (meta.series_as_of, examples of which series are lagging), which covers the major gap. Not perfect because there is no explicit statement of what the tool does if months is out of range (but schema enforces), and no mention of the openWorldHint meaning (allowed to make best-effort). Overall, description is complete for practical use.

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 description coverage is 100%; the schema fully documents the parameters (months range 1-240 default 24; indicators list with all names and formats). The description adds the caveat about series freshness related to months, but doesn't add significant new meaning beyond the schema. Baseline of 3 is appropriate given the schema's thorough documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('조회한다' - retrieves), clearly names the resource (Korean base rate, KOSPI, M2, US Fed rate, S&P500 monthly time series), and explicitly states its use case ('금리가 집값에 어떤 영향?' background analysis). It distinguishes itself from the many sibling tools by focusing on macroeconomic monthly time series, not property-specific data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool (for background analysis related to macro indicators and their effect on housing prices), and the caution about series freshness provides clear guidance: don't cite stale series as current, and always report the series-specific as-of date. While it doesn't explicitly name alternatives, the specific use case and the warning about currency sufficiently route the agent. The openWorldHint annotation and sibling names clarify what other tools are for individual areas.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All korea-realty toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources