Skip to main content
Glama
taylee9809

budongsan-tax

by taylee9809
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Same household test

judge_same_household
Read-onlyIdempotent

Decide whether two people form one household for Korean income, acquisition, or holding tax by evaluating relationship, cohabitation, livelihood, age, and tax rules.

Instructions

Decide whether two people form one household (1세대) for income, acquisition or holding tax purposes.

트리① — 본인과 특정인의 1세대 동일성 판정 (소법 §88 6호·영 §152의3 / 지방령 §28의3 / 종부령 §1의2).

relationship: 배우자|직계존속|직계비속|직계존비속의 배우자|형제자매|기타(이모·조카 등 —
가족 범위 밖은 세목 불문 별도 세대).

⚠️ 세대 정의는 세목마다 다르다 — tax_kind를 반드시 맞춰 넣을 것:
  양도세는 같은 주소 + 생계동일(실질), 취득세는 세대별 주민등록표 기준.
  사실혼 배우자는 취득세에서 명문 제외(is_de_facto_marriage).
  미혼 30세 미만 자녀는 취득세에서 주민등록을 분리해도 같은 세대이고, 별도세대가 되려면
  **직전 12개월** 소득이 중위소득 40% 이상이어야 한다(양도세는 측정기간 명문 없음).
  동거봉양 합가 별도세대 예외는 취득세가 **65세**, 양도세 §155④ 특례는 60세다
  (merged_for_parent_care·descendant_age로 취득세 판정).
legally_divorced_but_living_together: 법률상 이혼했으나 사실상 이혼으로 보기 어려운 관계는
  배우자에 포함된다(소법 §88 6호 괄호 — 위장이혼 차단).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNo
is_minorNo
tax_kindNo양도세
relationshipYes
descendant_ageNo
lives_togetherNo
is_married_or_wasNo
shares_livelihoodNo
is_de_facto_marriageNo
merged_for_parent_careNo
income_over_40pct_medianNo
legally_divorced_but_living_togetherNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantial non-obvious behavior beyond that: the definition varies per tax kind, de facto marriage is expressly excluded in acquisition tax, under-30 unmarried children need 12-month income above 40% median, and the care-merge exception age differs (65 vs 60). This is real decision context, though it omits anything about the shape of the verdict returned.

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 purpose is front-loaded, and the tax_kind warning plus the per-tax bullet structure make it scannable despite being dense. It is somewhat verbose and mixes legal citations with operational guidance, but no sentence is clearly wasteful.

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?

Given 12 parameters, a single required field, no output schema, and the complexity of a tax-law household test, the description supplies the essential per-tax rules and exceptions. It is close to complete for the inputs, with the main gap being that it never states what the judgment returns.

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 0% across 12 parameters, so the description must compensate and does so only partially. It clarifies relationship values, tax_kind, is_de_facto_marriage, merged_for_parent_care, descendant_age, and legally_divorced_but_living_together, but leaves age, is_minor, lives_together, is_married_or_was, and shares_livelihood unexplained.

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 opens with a specific verb+resource: 'Decide whether two people form one household (1세대) for income, acquisition or holding tax purposes.' It scopes the tool precisely (household-identity determination) and cites the governing legal bases, which lets an agent distinguish it from status-oriented siblings like judge_jongbu_one_home_status or judge_155_special.

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

Usage Guidelines4/5

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

It gives explicit conditional guidance: tax_kind must be matched, and it details how the household definition diverges between 양도세 (same address + shared livelihood) and 취득세 (resident-registration table). It does not, however, name sibling tools as alternatives for adjacent determinations, so it stops short of full routing guidance.

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

Deploy Server

Other Tools