Skip to main content
Glama

양도세 계산 — 선언된 양도·취득·보유에 세율표 적용, 합산/연도분산/차손통산 비교

realty_capital_gains_tax
Read-onlyIdempotent

선언된 양도가·취득가·필요경비·보유기간에 양도소득세 세율표를 결정론으로 적용한다 — 기본·단기·분양권 세율, 장특공제 표1, 기본공제, 다주택 중과(선언), 지방소득세 10%. 두 번째 자산을 주면 같은 해 합산 vs 연도분산 vs 차손통산을 비교해 어느 쪽이 유리한지 산출한다. "지금 팔면 양도세 얼마?"·"두 채를 올해 같이 팔까 나눠 팔까?"의 자리다.

경계를 지켜라: ① 입력 전부 **선언**이다 — 보유기간 기산·주택 수·조정대상지역 해당은
사실판단이라 서버가 판정하지 않는다. ② **1세대1주택 비과세·12억 초과 고가주택 안분·
감면 특례는 계산하지 않는다**(not_curated) — 이 결과는 양도 전액이 과세된다는 전제다.
**그렇다고 사용자를 밖으로 내보내지 마라 — 계산기가 없을 뿐 갈림길 지도는 우리에게
있다**: `realty_policy_rules(topic='one_home_exemption_map')`이 5관문(세대·1주택·
보유2년·조정지역 거주2년·12억)과 5경로(일시적2주택·상속·합가·부득이한 사유·상생임대)를
확인 체크리스트와 함께 준다. 비과세 가능성이 보이면 **거기부터** 가고, 그 관문을 다 훑고도
사실판단이 남을 때 비로소 홈택스 모의계산·세무사를 안내하라. ③ 세율표·필요경비 분류·중과
경과조치의 원문·근거 조문은 realty_policy_rules(topic=capital_gains_tax)가 진실원이고,
조정대상지역 지정 현황은 topic=regulated_area다.
응답의 traps·pending_legislation·disclaimer를 함께 전하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
share_pctNo본인 지분율(%, 공동명의면 예: 50). 양도세는 인별 과세라 본인 지분만 계산하고 기본공제 250만원도 각자 받는다 — 배우자 몫은 배우자 지분으로 따로 호출하라. 두 자산 모두에 같은 지분을 적용한다 (허용 범위 0 초과~100)
asset_typeNo자산 종류 — 단기세율·장특공제가 갈린다. 분양권은 보유 2년이 넘어도 60%다주택
holding_yearsYes보유기간(년, 소수 허용 — 예: 1.5). 취득일~양도일이며 상속·증여 기산 특례는 사실판단이라 호출자가 확정해 선언한다 (허용 범위 0~100)
transfer_yearYes양도(예정) 연도. 2027 이후는 계류 중인 세제개편안이 결과를 뒤집을 수 있어 응답에 실토가 붙는다. 2025 이전 과거 양도는 당시 규칙(중과 유예 등)이라 다루지 않는다 (허용 범위 2026~2035)
asset2_asset_typeNo두 번째 자산의 종류주택
transfer_price_10kYes양도가액(만원, 예: 90000=9억). 예정이면 예상 매도가를 선언
asset2_expenses_10kNo두 번째 자산의 필요경비(만원)
asset2_holding_yearsNo두 번째 자산의 보유기간(년) — **transfer_year 기준**이다. 연도분산 시나리오는 이 자산을 다음 해에 파는 가정이라 서버가 보유기간을 +1년으로 다시 계산한다(응답 scenarios.split_years.asset2_recomputed에 실토) (허용 범위 0~100)
multi_home_surchargeNo다주택 중과 **선언** — 양도 시점에 그 주택이 조정대상지역 안이고(현재 지정 현황은 topic=regulated_area) 세대 주택 수가 2/3+인 경우. 주택 수 판정(분양권·입주권 가산, 지방 저가주택 제외)은 사실판단이라 서버가 하지 않는다없음
acquisition_price_10kYes취득가액(만원). 증여받은 자산은 이월과세(10년)로 증여자 원취득가가 될 수 있다 — 응답 traps 확인
necessary_expenses_10kNo필요경비 합계(만원) — 취득·양도 부대비용과 자본적 지출만. 도배·싱크대 같은 수익적 지출은 불인정이다(경계·증빙 요건은 topic=capital_gains_tax 원문)
asset2_transfer_price_10kNo두 번째 자산의 양도가액(만원) — 주면 '올해 같이 팔기 vs 내년으로 나누기' 시나리오를 비교한다. asset2_acquisition_price_10k·asset2_holding_years와 함께 줘야 한다
asset2_multi_home_surchargeNo두 번째 자산의 중과 선언 — 첫 자산 매도 후 주택 수가 줄어 지위가 달라질 수 있다. 시나리오별 지위 변화도 선언 그대로 쓴다(서버는 판정하지 않는다)없음
asset2_acquisition_price_10kNo두 번째 자산의 취득가액(만원)

TDQS

A4.6/5.0
Behavior5/5

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

Annotations (readOnly, idempotent, non-destructive) are rich, because the description builds further: the '모든 입력은 선언' oversight rule where the server Judgements facts; the stated assumption that 양도 전액이 과세; that a second asset triggers re-computation of holding years (+1) for split-year scenario disclosed in scenarios.split_years.asset2_recomputed; that pre-2025 transfers and post-2026 pending legislation cause uncertainty (traps/changements) plus mandate to pass via traps·pending_legislation·disclaimer. Beyond the 2026–2026 support range is arrayed. No contradiction with annotations (pure computes/read-only).

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?

Long density is use-safe: front-loaded purpose then the key boundary caveat (not_curated, plained a decisive fork map realty_policy_rules) before any secondary guidance. The three paragraph sections (what it does / boundaries+routing / source-of-truth+delivery mandate) each earn their place; zero filler. For a 14-param tax tool with no output schema, this length is necessary and well-structured overall.

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 complexity+no output schema, the description covers the computation breadth, the declared-input boundary, exclusions, the routing to topic siblings and third-party guidance, and names required response fields (traps, pending_legislation, disclaimer, split.asset2_recomputed). The only gap: the presence of outlined singled-asset return value (the computed tax amount seems implied by '산출한다' but not inspi), so an agent's reply is concise — minor given the amount of guidance otherwise holds.

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% with highly detailed per-parameter docs (share_pct при-person, holding_years, fact declaration, asset2_holding_years recomputation, multi_home_surcharge declaration semantics). The description contributes the two-asset conditional behavioral framing (correctly: '두 번째 자산을 주면...') and the mental model of '입력은 모두 declaration', but does not add new individual-parameter meaning beyond what the schema's rich property descriptions already provide. Baseline 3 is correct when the schema carries the burden.

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?

States a specific verb+resource: applies 양도소득세 세율표 deterministically to declared transfer/acquisition/cost/holding inputs, and with a second asset computes '같은 해 합산 vs 연도분산 vs 차손통산' comparisons. It explicitly contrasts itself with realty_policy_rules and orients the agent with canonical questions ('지금 팔면 양도세 얼마?', '두 채를 올해 같이 팔까 나눠 팔까?'). This distinguishes it from all 56 siblings without needing to open schemas.

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?

Automatically: when to use (selling decision, multi-asset compare), when NOT to use (1세대1주택 exception, 고가주택 12억 안분, 감면 특례 — explicitly not_curated), and then explicit alternatives: realty_policy_rules(topic='one_home_exemption_map') with the 5-gate/5-path, realty_policy_rules(topic=capital_gains_tax) for the source, topic=regulated_area for zone map. It even prescribes the route to be followed ('everything from exemption map first, only if factual remains go to 홈택스/세무사'). Beyond explicit.

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.