Skip to main content
Glama
dolseom

gongsi-mcp

by dolseom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

공시의무 진단·기한 계산

check_disclosure_duty

Determines whether a disclosure duty applies under Korea's Fair Trade Act, calculates filing deadlines and expected fines for late disclosure, and flags missing data.

Instructions

공정거래법상 공시의무 대상 여부를 판정하고 공시기한·지연 시 예상 과태료를 계산합니다. 외부 API를 쓰지 않으므로 인증키 없이 동작합니다.

판정 결과에는 항상 근거 조문과 계산식이 포함됩니다. 자본총계·자본금이 없으면 추정하지 않고 insufficient_data 를 반환하므로, 그때는 get_financials 로 재무수치를 먼저 조회하세요.

⚠️ 거래금액 산정 방식(amountBasis)에 주의하세요 — 담보제공은 담보한도액, 부동산임대차는 연간임대료+보증금환산액, 보험은 보험료총액, 상품·용역은 분기 합계액입니다. 틀리면 판정이 뒤집힙니다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dutyYes공시의무 유형. large_internal_transaction=대규모내부거래(법§26), unlisted_material=비상장사 중요사항(법§27), group_status=기업집단현황(법§28), public_interest_corp=공익법인(법§29), omnibus_financial=약관에 의한 금융거래 특례(고시§9), goods_services_reduced=상품·용역 20%↑ 감소(고시§9의2)
yearNo연도 (기업집단현황)
todayNo오늘 날짜 (기본: 시스템 날짜). D-day 계산 기준
amountNo거래금액 (원). 기준금액과 비교해 공시 대상 여부를 판정하고, 지연 시 과태료의 거래금액별 적용비율(고시 Ⅵ.2 — 100억원 미만이면 90~50%)에도 쓰인다. 약관 금융거래는 분기 일괄 거래금액, 상품·용역 감소 특례는 실제 거래금액을 넣는다
listingNo상장 여부. 대규모내부거래 기한이 갈린다 (상장 3영업일 / 비상장 7영업일)
quarterNo분기. 지정하면 분기공시(종료 후 2개월), 생략하면 연1회(5/31)
boardDateNo이사회 의결일 (대규모내부거래·공익법인)
situationNo거래 상황 서술 (예: "계열사 발행어음이 만기 후 자동연장됨", 500자 이내). 주면 유사한 공정위 공식 Q&A를 relatedOfficialQna 로 함께 돌려줍니다 — 규칙만으로 판정하기 어려운 경계사례(대상 여부·거래 성격)에 유용합니다
quarterEndNo분기 종료일 (약관 금융거래·상품용역 감소)
amountBasisNo거래금액 산정 방식 (고시§4③). ⚠️ 틀리면 판정이 뒤집힌다. collateral_limit=담보제공은 담보한도액, lease_annualized=부동산임대차는 연간임대료+보증금환산, insurance_premium_total=보험은 보험료총액, quarterly_sum=상품용역은 분기 합계액
totalAssetsNo자산총액 (원). 비상장사 중요사항 중 고정자산 판정용
totalEquityNo자본총계 (원). 주총 승인된 최근 사업연도말 재무제표 기준
materialItemNo비상장사 중요사항 세부 항목. 임계 비율형: fixed_asset=고정자산 취득·처분(자산총액 10%), other_corp_stock=타법인 주식(자기자본 5%), gift=증여(1%), guarantee=담보·보증(5%), debt_relief=채무 면제·인수(5%), shareholding_change=최대·주요주주 지분 1%p 변동. 금액 무관 결정형: capital_change=증자·감자, cb_bw_issue=CB·BW 발행, business_transfer=영업양수도·합병·분할, stock_exchange_transfer=주식 포괄적 교환·이전, dissolution=해산, rehabilitation=회생절차, restructuring_procedure=기촉법 관리절차
occurredDateNo사유 발생일 (비상장사 중요사항)
paidInCapitalNo자본금 (원). 이사회 의결일 직전일 기준
shareChangePctNoshareholding_change 전용 — 발행주식총수 대비 지분 변동 크기 (%p). 1 이상이면 공시 대상
boardResolutionNo과태료 산정용: 이사회 의결을 실제로 거쳤는지. 대규모내부거래·공익법인(§26 계열)에서 의결 없이 공시하거나 미공시한 사건은 별표 9의 "의결 X" 칸(기본금액 5,000만~7,000만원)이 적용되어 금액이 크게 달라집니다. 생략하면 의결을 거친 것으로 가정하고 그 가정을 caveat 로 알립니다
shareholderTypeNoshareholding_change 전용 — largest=최대주주(7영업일 공시) / major=주요주주(분기별 공시, 고시 §5의2④ 단서). 기한이 완전히 달라지므로 반드시 구분하세요
disclosureStatusNo공시 이행 상태. not_disclosed(아직 공시 전)를 명시하면 기한 경과 시 자진시정 골든타임을 계산합니다. 생략하면 미공시로 단정하지 않습니다 — 기한만 조회하는 호출과 구분하기 위한 명시적 입력입니다
isFinancialCompanyNo금융업·보험업 영위 여부 (비상장사 중요사항 대상회사 판정용 — 영위하면 제외)
specialRelated20pctNo자산총액 100억 미만 회사의 대상 판정용 — 동일인·친족이 합산 20% 이상 소유한 회사(또는 그 회사가 50% 초과 소유한 자회사)인지 (고시 §2②2호)
actualDisclosureDateNo실제 공시일. 주면 기한 준수 여부와 지연일수를 함께 판정한다
estimatePenaltyIfLateNo지연이 확인되면 예상 과태료도 함께 산정할지 (기본 true)
inLiquidationOrDormantNo청산 절차 진행 중 또는 1년 이상 휴업 중인지 (고시 §2②2호 단서의 제외 요건)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / boardResolution
      Added value: +{
+  "description": "과태료 산정용: 이사회 의결을 실제로 거쳤는지. 대규모내부거래·공익법인(§26 계열)에서 의결 없이 공시하거나 미공시한 사건은 별표 9의 \"의결 X\" 칸(기본금액 5,000만~7,000만원)이 적용되어 금액이 크게 달라집니다. 생략하면 의결을 거친 것으로 가정하고 그 가정을 caveat 로 알립니다",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the transparency burden and does so well: it discloses that the tool does not call external APIs and requires no auth key, always includes 근거 조문 and 계산식 in results, and returns insufficient_data instead of estimating missing financial figures. It does not state side-effect/read-only behavior, but the disclosed traits substantially inform invocation.

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-structured: core function first, then output guarantees and the missing-data fallback, then a high-impact warning about amountBasis. Every sentence contributes actionable information, and the critical warning is clearly marked and front-loaded.

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 24 parameters, no output schema, and no annotations, the description is reasonably complete for tool selection and safe invocation: it states the computation scope, result contents, missing-data behavior, and a key input pitfall. It does not enumerate every duty-specific parameter combination, but the richly documented schema compensates for that gap.

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 description coverage is 100%, so the schema already documents all parameters. The description adds semantic value by highlighting amountBasis as decision-critical and by explaining the insufficient_data behavior tied to totalEquity/paidInCapital, plus routing to get_financials. This goes beyond the baseline but does not exhaustively synthesize all 24 parameters.

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 opens with a specific verb and resource: '공정거래법상 공시의무 대상 여부를 판정하고 공시기한·지연 시 예상 과태료를 계산합니다.' This clearly identifies the tool's core function and differentiates it from sibling audit/search tools in substance, though it does not explicitly name or contrast any sibling tool.

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 provides an explicit conditional alternative: when 자본총계·자본금 are missing, the tool will not estimate and returns insufficient_data, and the agent should 'get_financials 로 재무수치를 먼저 조회하세요.' This gives a concrete when-not-to-use instruction and a named alternative. General when-to-use context is implied by the purpose statement but not elaborated for all duty types.

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