Skip to main content
Glama
quickquickTax

Korean Capital Gains Tax Advisor MCP Server

by quickquickTax
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

바로바로 양도소득세

바로바로 양도소득세는 대한민국 부동산 양도 사건을 구조화하고, 계산 가능 여부를 먼저 검증한 뒤 예상 양도소득세와 개인지방소득세를 설명 가능한 형태로 계산하는 MCP 서버입니다.

이 서비스의 결과는 검토용 예상값이며 확정 신고세액이나 세무 자문이 아닙니다. 현재 세법 규칙은 pending_professional_review 상태입니다.

서비스가 해결하는 문제

부동산 양도소득세는 자산 유형, 취득·양도 시점, 필요경비, 보유·거주기간, 주택 수, 공동명의 여부에 따라 결과가 달라집니다. 사용자가 일부 조건을 누락한 채 바로 계산하면 잘못된 결과가 나올 위험이 큽니다.

이 MCP는 다음 순서로 동작합니다.

  1. 개인정보 없이 필요한 거래 정보를 질문으로 수집합니다.

  2. 날짜 표현을 YYYY-MM-DD 형식으로 정규화합니다.

  3. 금액 표현을 원 단위 숫자로 정규화합니다.

  4. 계산 전 체크리스트로 누락값, 모순된 조건, 미지원 사건을 구분합니다.

  5. 입력 사건이 계산 가능한지 검증합니다.

  6. 검증을 통과한 사건만 결정론적으로 계산합니다.

  7. 세액, 계산 단계, 적용 규칙 버전과 주의사항을 반환합니다.

Related MCP server: Korea Real Estate MCP

주요 기능

  • 양도가액·취득가액·필요경비 기반 양도차익 계산

  • 보유기간과 거주기간 검증

  • 장기보유특별공제와 기본공제 계산

  • 양도소득세와 개인지방소득세 계산

  • 단독명의·공동명의 지분별 계산

  • 공동명의와 단독명의 가정 결과 비교

  • 2026.01.01, 260101, 20250101~20260101 같은 날짜 입력 정규화

  • 7.5억, 7억5000만, 750,000,000 같은 금액 입력 정규화

  • 아파트, 상가, 사업용 토지 같은 자산 종류 정규화

  • 샀어요, 상속받음, 증여 같은 취득 방법 정규화

  • 네, 아니요, 모름 같은 예/아니오 답변 정규화

  • 1채, 한 채, 두 채 같은 주택 수 정규화

  • 세무사가 확인했어요, 아직 검증 안 했어요 같은 비과세 검증 상태 정규화

  • 단독명의, 부부 반반, 저 60 배우자 40 같은 소유 형태 정규화

  • 취득세, 복비, 법무사비, 자본적 지출 같은 필요경비 정규화

  • 목적 caseData 필드 기준 통합 정규화와 caseDataPatch 생성

  • 계산 전 누락값 질문과 위험 체크리스트 생성

  • 1세대 1주택 비과세 요청의 일관성 검증

  • 규칙 적용기간과 양도일 불일치 차단

  • 상속·증여 취득과 동일 연도 복수 양도 등 미지원 사건 차단

  • 증빙이 확인되지 않은 필요경비 차단

MCP 도구

normalize_case_input

양도일, 양도가액, 취득일, 취득가액, 취득 방법, 자산 종류, 소유 형태, 주택 수, 거주기간, 예/아니오 답변, 비과세 검증 상태, 필요경비 같은 사용자 답변을 목적 caseData 필드에 맞게 정규화하고 caseDataPatch를 반환합니다.

지원 예시:

  • targetField=transfer.price, rawValue=7억 5천만 → { "transfer": { "price": 750000000 } }

  • targetField=acquisition.date, rawValue=250101 → { "acquisition": { "date": "2025-01-01" } }

  • targetField=annualContext.otherTransfersExist, rawValue=아니요 → { "annualContext": { "otherTransfersExist": false } }

normalize_asset_input

아파트, 빌라, 상가, 사업용 토지, 비사업용 토지 같은 사용자 표현을 asset.subType 후보로 변환합니다.

normalize_acquisition_method_input

샀어요, 매매, 상속받음, 증여 같은 사용자 표현을 acquisition.method 값으로 변환합니다.

normalize_boolean_input

네, 아니요, 없음, 모름 같은 답변을 boolean 또는 unknown으로 변환합니다.

normalize_duration_input

2년, 2년 6개월, 30개월, 거주 안 함 같은 답변을 household.residenceYears에 사용할 정수 연 단위 값으로 변환합니다.

normalize_count_input

1채, 한 채, 두 채, 없음 같은 답변을 household.houseCount에 사용할 정수 값으로 변환합니다.

normalize_exemption_verification_input

세무사가 확인했어요, 아직 검증 안 했어요, 해당 없음, 모르겠어요 같은 답변을 household.exemptionVerificationStatus 값으로 변환합니다.

normalize_ownership_input

단독명의, 부부 공동명의, 반반, 저 60 배우자 40 같은 답변을 ownership 구조로 변환합니다.

normalize_expense_input

취득세 1200만원 증빙 있음, 복비 500만원, 법무사비 같은 답변을 expenses 항목 구조로 변환합니다.

normalize_date_input

사용자가 입력한 날짜 또는 기간 표현을 계산 도구가 사용하는 YYYY-MM-DD 형식으로 변환합니다.

지원 예시:

  • 2026.01.01 → 2026-01-01

  • 260101 → 2026-01-01

  • 2025.01.01.-2026.01.01 → 2025-01-01, 2026-01-01

  • 250101-260101 → 2025-01-01, 2026-01-01

  • 20250101~20260101 → 2025-01-01, 2026-01-01

normalize_amount_input

사용자가 입력한 금액 표현을 계산 도구가 사용하는 원 단위 정수로 변환합니다.

지원 예시:

  • 750,000,000 → 750000000

  • 7.5억 → 750000000

  • 7억 → 700000000

  • 7억5000만 → 750000000

  • 7억 5천만 → 750000000

prepare_capital_gains_case_checklist

사용자 답변을 누적한 caseData를 기준으로 계산 전 체크리스트와 질문 그룹을 생성합니다.

확인 항목:

  • 거래 핵심값: 양도일, 취득일, 양도가액, 취득가액

  • 자산 종류와 토지 사업용 여부

  • 단독명의·공동명의와 지분율

  • 주택 수, 거주기간, 조정대상지역 여부

  • 1세대 1주택 비과세 요청과 전문가 검증 여부

  • 상속·증여 취득, 동일 연도 복수 양도 등 미지원 위험

  • 필요경비와 증빙 보유 여부

반환값에는 기존 questions 배열과 함께 questionGroups가 포함됩니다. questionGroups는 거래 정보, 자산 정보, 소유 형태, 세대 및 비과세, 과세연도 맥락, 필요경비 및 증빙, 지원 범위, 검증 결과 확인 순서로 질문을 묶어 반환합니다.

validate_capital_gains_case

계산 전에 필수 입력, 날짜, 소유 지분, 비과세 조건, 필요경비 증빙과 지원 범위를 검사합니다.

서비스 범위는 국내 등기 자산으로 고정되어 있으며, 국내 자산 여부와 등기 여부는 사용자에게 별도로 입력받지 않습니다.

주요 결과:

  • complete: 계산 가능

  • invalid: 입력 누락 또는 모순

  • unsupported: 현재 엔진의 지원 범위 밖

  • validForCalculation: 계산 도구 호출 가능 여부

  • issues: 수정하거나 확인해야 할 항목

calculate_capital_gains_tax

검증된 사건을 받아 예상 양도소득세와 개인지방소득세를 계산합니다.

주요 결과:

  • 총 예상세액

  • 양도소득세와 개인지방소득세

  • 양도차익, 공제액과 과세표준

  • 적용 세율 유형

  • 공동명의 소유자별 결과

  • 규칙 버전, 가정과 경고

list_supported_capital_gains_scenarios

지원 기준일, 계산 가능한 사건, 미지원 사건과 사용상 주의사항을 반환합니다.

대화 사용 예시

사용자: 2018년에 3억원에 산 아파트를 2026년에 6억원에 팔 예정입니다.
       취득세와 중개수수료로 2천만원을 지출했습니다. 예상 세금을 계산해 주세요.

AI: 계산에 필요한 주택 수, 거주기간, 조정대상지역 여부,
    비과세 적용 요청과 증빙 상태를 추가로 확인합니다.

AI는 사용자 답변이 자연어로 들어오면 해당 normalize_* 도구로 계산 스키마에 맞게 변환한 뒤 caseData에 누적합니다. 이후 prepare_capital_gains_case_checklist, validate_capital_gains_case 순서로 호출하고, 검증을 통과한 경우에만 calculate_capital_gains_tax를 호출해야 합니다.

각 정규화 도구는 targetField, normalizedValue, readyForCaseData를 공통으로 반환합니다. readyForCaseData=false이면 사용자 확인을 먼저 받아야 합니다.

PlayMCP 호환성

  • MCP 프로토콜: 2025-03-26 ~ 2025-11-25

  • 전송 방식: Streamable HTTP

  • 서버 방식: Stateless

  • 도구 개수: 14개

  • 도구 이름: PlayMCP 문자 규칙 준수

  • 도구 설명: 영문 중심, 영문·국문 서비스명 병기

  • 필수 annotations 제공

    • title

    • readOnlyHint=true

    • destructiveHint=false

    • openWorldHint=false

    • idempotentHint=true

카카오클라우드 배포

Agentic Player 10 제출용 배포에는 저장소 루트의 Dockerfile을 사용합니다. Dockerfile.kakao도 같은 배포 설정을 유지합니다.

PlayMCP in KC의 Git 소스 빌드 화면에 다음 값을 입력합니다.

Git URL: 이 저장소의 URL
브랜치/ref: main
Dockerfile 경로: Dockerfile.kakao
PAT: 공개 저장소라면 비워두기

카카오용 이미지는 다음 조건으로 실행됩니다.

  • linux/amd64

  • Node.js 20

  • 컨테이너 포트 3000

  • POST /mcp: MCP Endpoint

  • GET /health: 상태 확인

  • API 키와 Authorization 헤더 불필요

  • 사용자 입력과 계산 결과를 서버에 저장하지 않음

  • 요청 본문을 로그에 기록하지 않음

상세 절차는 docs/kakao-cloud-deployment.md를 참고하세요.

로컬 검증

npm ci
npm run check
npm run smoke:http:kakao

검증 항목:

  • TypeScript 빌드

  • 단위·회귀 테스트

  • Streamable HTTP 초기화

  • 도구 목록과 PlayMCP annotations

  • 무인증 Endpoint 호출

카카오용 Docker 이미지 직접 빌드:

docker build --platform linux/amd64 \
  -f Dockerfile.kakao \
  -t kr-capital-gains-tax-mcp:kakao .

프로젝트 구조

src/
├─ http-server.ts          Streamable HTTP 서버
├─ mcp-server.ts           MCP 도구 등록과 annotations
├─ domain/                 계산·검증 도메인 로직
├─ rules/                  기준일별 세법 규칙 데이터
└─ tools/                  MCP 입력 스키마와 도구 어댑터

tests/
├─ unit/                   날짜·세율·검증·공동명의 테스트
└─ regression/             대표 계산 사례 회귀 테스트

안전장치

  • 누락값을 임의로 추정하지 않습니다.

  • 검증 실패 사건은 계산하지 않습니다.

  • 규칙 적용기간 밖의 사건은 계산하지 않습니다.

  • 미검증 비과세 요청은 계산하지 않습니다.

  • 무증빙·기타 필요경비는 자동 공제하지 않습니다.

  • 각 결과에 규칙 버전, 가정과 경고를 포함합니다.

  • 계산 도구는 외부 상태를 변경하지 않습니다.

현재 지원하지 않는 사건

  • 동일 과세기간 복수 양도와 양도차손 통산

  • 상속·증여·부담부증여 취득

  • 일시적 2주택, 상속주택과 특례주택 판정

  • 조합원입주권과 분양권

  • 감면, 가산세, 외국납부세액

  • 국외 자산, 법인과 비거주자

  • 전자신고와 신고서 자동 제출

중요 고지

현재 규칙 데이터는 공식 법령과 신고 서식에 대한 최종 전문 검토가 완료되지 않았습니다. 실제 신고, 납세 의사결정 또는 고객 제공 전에는 세무 전문가의 검토가 필요합니다.

Available Tools

3 tools
calculate_capital_gains_tax양도소득세 예상 계산A
Read-onlyIdempotent

Korean Capital Gains Tax Advisor(한국 양도소득세 도우미) deterministically estimates Korean real-estate capital gains tax and local income tax from a complete, validated case. It rejects unsupported cases such as multiple transfers in one tax year or acquisition by inheritance or gift. Results are estimates for review, not final filing amounts.

ParametersJSON Schema
NameRequiredDescriptionDefault
caseDataYes검증과 계산에 필요한 완전한 양도소득세 사건 데이터

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds behavioral context: it rejects unsupported cases, is deterministic, and provides estimates. No contradictions.

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 three sentences with purpose, constraints, and disclaimer. It is front-loaded and efficient. Minor bilingual mix (English/Korean) could be streamlined but does not hinder clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers tool behavior and limitations but lacks output schema details. It mentions estimates for tax and local income tax but no info on return structure. Given nested input complexity, output specification would enhance completeness.

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 detailed types and descriptions. The description adds only that the input must be 'complete, validated case,' which is already implied by the schema's required fields and descriptions. No extra parameter-level detail beyond schema.

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 clearly states the tool 'deterministically estimates Korean real-estate capital gains tax and local income tax from a complete, validated case,' specifying the verb (estimates), resource (tax), and scope. It distinguishes from siblings: list_supported_capital_gains_scenarios and validate_capital_gains_case are different functions.

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?

The description lists rejected cases (multiple transfers, inheritance/gift) and notes results are estimates, providing guidance on when not to use. It implies use for complete validated cases but lacks explicit comparison with siblings.

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

list_supported_capital_gains_scenarios지원 범위 확인A
Read-onlyIdempotent

Korean Capital Gains Tax Advisor(한국 양도소득세 도우미) lists supported rule dates, scenarios that can be calculated, unsupported cases, and important usage cautions. Use this tool before collecting case details when support is uncertain.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailLevelNofull

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and idempotentHint=true, indicating safe behavior. The description adds value by specifying that the tool lists unsupported cases and cautions, beyond what annotations provide.

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?

Two concise sentences: first states what the tool does, second provides usage guidance. No unnecessary words, front-loaded with key information.

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 the simple parameter, rich annotations, and clear siblings, the description is sufficient. It describes the output types (supported scenarios, unsupported cases, cautions) without needing an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention the 'detailLevel' parameter or its enum values. The parameter is simple but description fails to add meaning.

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 clearly states the tool lists supported rule dates, scenarios, unsupported cases, and usage cautions. It is a distinct pre-check tool compared to siblings 'calculate_capital_gains_tax' and 'validate_capital_gains_case'.

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?

Explicitly advises using this tool before collecting case details when support is uncertain, providing clear context for use. It does not explicitly state when not to use, but the guidance is strong.

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

validate_capital_gains_case양도소득세 사건 입력 검증A
Read-onlyIdempotent

Korean Capital Gains Tax Advisor(한국 양도소득세 도우미) validates required fields, dates, ownership shares, rule applicability, and supported scenarios before calculating Korean real-estate capital gains tax. Call this tool first and do not infer missing values.

ParametersJSON Schema
NameRequiredDescriptionDefault
caseDataYes검증할 양도소득세 사건 데이터. 일부 필드만 전달해도 됩니다.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds specifics on what gets validated (required fields, dates, shares, rules, scenarios) and the instruction not to infer missing values, providing useful context beyond annotations.

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?

Two sentences, zero wasted words. First sentence states purpose and scope, second sentence gives critical usage instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers what it validates and usage order, but does not indicate what the output is (validation errors/success, or return structure). Given no output schema, this gap reduces completeness for a validation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but parameter description is minimal ('data to validate; partial fields okay'). Tool description adds value by detailing what aspects are validated, enhancing meaning for the single parameter.

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 clearly states it validates required fields, dates, ownership shares, rule applicability, and supported scenarios before calculating Korean real-estate capital gains tax. It also distinguishes itself from sibling tools by specifying 'call this tool first'.

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?

Explicitly says 'Call this tool first and do not infer missing values,' providing clear when-to-use and when-not-to-use guidance relative to calculate_capital_gains_tax.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedcalculate_capital_gains_tax
    • First observedlist_supported_capital_gains_scenarios
    • First observedvalidate_capital_gains_case
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: listing supported scenarios, validating a case, and calculating tax. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'verb_noun' pattern in snake_case (calculate_capital_gains_tax, list_supported_capital_gains_scenarios, validate_capital_gains_case).

Tool Count5/5

Three tools cover the essential workflow of discovery, validation, and calculation, appropriate for a focused tax advisor server.

Completeness5/5

The tool set covers the full lifecycle: check what's supported, validate a case, then calculate. No obvious missing operations for the stated purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • 2025 Tax Law Amendment MCP

    CheolMinBae
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to search and query information from the 2025 Korean tax law amendment PDF documents using natural language. Provides document indexing and retrieval capabilities through ChromaDB vector storage and LangChain integration.
    -

  • Korea Real Estate MCP

    tae0y
    A
    license
    A
    quality
    A
    maintenance
    Connects to Korea's MOLIT real estate API to provide 14+ tools for live transaction data and financial scenarios like buy now, buy later, or invest only based on income and savings.
    16
    373
    MIT

  • mcp-finance-tools

    jack200250-collab
    F
    license
    A
    quality
    C
    maintenance
    Provides Korean-specific financial calculators (4 insurances, salary net, severance pay, capital gains tax, DSR/DTI, FX conversion, housing subscription score) as MCP tools for AI agents.
    7
    -

  • MOLIT Real Estate Transactions

    jeon3709-dev
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables natural language queries to retrieve Korean real estate transaction data (land, commercial, apartments) from the public API, returning structured tables and summary statistics.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/quickquickTax/yangdoAngel'

If you have feedback or need assistance with the MCP directory API, please join our Discord server