Skip to main content
Glama

기업집단 구조 조회

get_group_structure

Retrieves the full list of affiliated companies and corporate group overview (same person, representative company, affiliate count) to define the population for FTC disclosure obligations.

Instructions

공정위 지정 기업집단의 개요(동일인·대표회사·소속회사 수)와 소속회사 전수를 돌려줍니다. 소속회사 목록이 곧 공정위 공시의무의 모집단입니다. EGROUP_API_KEY 필요.

  • DART corp_code 조인은 법인등록번호 기준입니다 — 이름 매칭은 포털과 DART 의 표기 체계가 달라 불가능합니다

  • 포털 데이터는 연 1회(매년 5/1) 갱신되며 연단위로 캐시됩니다

  • 집단명은 공정위 표기를 씁니다: "SK" 가 아니라 "에스케이"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupYes기업집단명("삼성", "에스케이") 또는 기업집단코드("K1000032")
compactNotrue 면 계열사를 schema+값 배열로 (150개사 집단에서 토큰 절감)
join_dartNoDART corp_code 조인 시도 (기본 true). 법인등록번호가 캐시에 채워진 회사만 조인됩니다 — joined 수가 적으면 resolve_entity(fetchJurirNo=true) 로 회사를 조회해 채우세요
year_monthNo기준 공개년월 (미지정 시 최신 지정연도 추정 — 매년 5월 갱신)
include_financialsNo계열사 재무현황 포함 (기본 false, 포털 호출 1회 추가). 자산총액·자본총액·자본금·부채·매출·당기순이익 (단위: 원). 자본총액·자본금은 check_disclosure_duty 의 totalEquity/paidInCapital 입력으로 쓸 수 있습니다

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and performs well: it discloses API key requirements, annual refresh cadence (매년 5/1) with yearly caching, the DART join limitation based on 법인등록번호 rather than names, and the FTC naming convention. These are precisely the behavioral caveats an agent needs.

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 tight and well-structured: a one-sentence purpose, one contextual sentence, and three focused bullet points. Every sentence adds value, with the most important caveats 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 no output schema, the description adequately states what is returned (overview plus full affiliate list) and covers auth, freshness, naming, and join limitations. Minor gaps include no explicit mention of output format for compact mode or financials, but those are covered in the parameter schema.

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%, so the baseline is 3. The description adds useful context for the group parameter (FTC naming convention, e.g., 에스케이 not SK) and reinforces the DART join logic, but these are mainly elaborations of what the schema already documents.

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 first sentence states a specific verb (돌려줍니다), a precise resource (공정위 지정 기업집단), and the return contents (개요와 소속회사 전수). It clearly distinguishes this structural data source from analytical siblings like check_disclosure_duty and audit_group_disclosures.

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 statement '소속회사 목록이 곧 공정위 공시의무의 모집단입니다' establishes clear context for when to use this tool. It also notes the EGROUP_API_KEY prerequisite. However, it does not explicitly name alternatives or state when not to use this tool.

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