Skip to main content
Glama

get_audit_profile

Read-onlyIdempotent

MyDART MCP의 get_audit_profile 도구는 감사인·감사의견·업무수행이사에 감사보수·감사투입시간·실사수행내역·외부조회 실시여부 등 외부감사 실시내역을 한 표로 요약해 반환합니다.

[Purpose]

  • Fact/figure asks: "who audited, at what fee, how was the 실사".

  • 강조사항 comes structured (emphasis); full 의견근거·KAM·강조 text: get_audit_report.

  • ICFR detail: get_internal_control; 계속기업 quant: get_going_concern.

  • Company lists (모집단): search_audit_findings.

[Usage]

  1. "삼성전자 2024 감사보수·비감사보수" → corp="삼성전자", year=2024

  2. "감사인·감사보수만 빠르게" → corp="…", year=2024, light=true

[Response]

  • fees _m suffix = 백만원.

  • opinion domain: 적정/한정/부적정/의견거절.

[Rules]

  • data_available=false = the filing was not found (e.g. not yet filed) — do NOT read null fields as "confirmed absent".

  • audit_only=true (F 단독공시, unlisted) → fees are structurally absent (사업보고서 전용), not a defect.

  • For 연결/별도 split read kam.by_fs_div, not kam.topics (representative fallback).

  • ALWAYS read applicability.guidance[] — regime notes and next-tool routing.

  • 감사인 교체/연속연수 are NOT returned — call per year and compare auditor.name.

Input Schema

NameRequiredDescriptionDefault
corpYes회사명/종목코드/corp_code
yearYes결산 사업연도 (회계연도·fiscal year), NOT the 공시(제출)연도 — pass the user's year as-is, never subtract: '2025 사업보고서' → 2025. Convert ONLY when the user explicitly names the 공시연도: '2026년에 공시된 사업보고서' → 2025. Relative ('최근 N개년'·'작년'): count back from the latest PUBLISHED 사업연도 (사업보고서 filed ≤90 days after 결산기말) — for 12월 결산 last year from April, the year before last in Jan~Mar (e.g. if latest = FY2025 → 최근 5개년 = 2021~2025). 비12월 결산 (3·6·9월): the year its 결산기 STARTS (3월 결산 2025-04~2026-03 = 2025; get_financials calls it 2026).
lightNoSkip 원문 parsing — structured JSON only, fast; omits 실사 (incl. fees.headcount), 연결/별도 split, engagement_partner
refreshNoBypass cache; re-collect

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / light / description
      Previous value: -"Skip 원문 parsing (structured JSON APIs only — omits 실사, the fs_div split, and fees.headcount, which comes from the 실사 source; fast)"New value: +"Skip 원문 parsing — structured JSON only, fast; omits 실사 (incl. fees.headcount), 연결/별도 split, engagement_partner"
    • changedInput schema / properties / refresh / description
      Previous value: -"Bypass the cache and re-collect"New value: +"Bypass cache; re-collect"
    • changedInput schema / properties / year / description
      Previous value: -"결산 사업연도 (회계연도, fiscal year) — the number you pass IS the 사업연도=회계연도=결산연도. Do NOT subtract it; pass it as-is. Only tools where year is optional auto-select the latest published year when omitted (if year is required in the tool you are calling, it cannot be omitted — confirm the year actually used via the response `year` field).e.g. 'FY2025'·'2025년 재무제표'·'2025 사업보고서'·'2025 회계연도' → all 2025 (결산일 2025-12-31). Convert ONLY when the user explicitly names the 공시(제출)연도, as in '○○년에 공시된 보고서': a 12월 결산법인 files by the end of March of the following year.(e.g. '2026년에 공시된 사업보고서' → 2025). Otherwise the input is ALWAYS on a 사업연도=회계연도=결산연도 basis. Relative expressions ('최근 N개년'·'작년' and the like) count back from the most recent PUBLISHED 사업연도 as of today: a 사업보고서 is filed within about 90 days after 결산 (12월 결산 법인 → March of the following year), so from April the latest is last year, and in Jan~Mar it is the year before last. e.g. if today is 2026-06 the latest is FY2025 → '최근 5개년'=2021~2025 (NOT 2020~2024). Supported floor is FY2015 (the range OpenDART's structured APIs cover) — 2014 and earlier are rejected. A 비12월 결산 (3·6·9월) 법인 may have its latest 사업연도 equal to the calendar year (e.g. a 3월 결산 company from July onward)."New value: +"결산 사업연도 (회계연도·fiscal year), NOT the 공시(제출)연도 — pass the user's year as-is, never subtract: '2025 사업보고서' → 2025. Convert ONLY when the user explicitly names the 공시연도: '2026년에 공시된 사업보고서' → 2025. Relative ('최근 N개년'·'작년'): count back from the latest PUBLISHED 사업연도 (사업보고서 filed ≤90 days after 결산기말) — for 12월 결산 last year from April, the year before last in Jan~Mar (e.g. if latest = FY2025 → 최근 5개년 = 2021~2025). 비12월 결산 (3·6·9월): the year its 결산기 STARTS (3월 결산 2025-04~2026-03 = 2025; get_financials calls it 2026)."
  2. Changed1 schema field changed
    • changedInput schema / properties / light / description
      Previous value: -"Skip 원문 parsing (structured JSON APIs only — omits 실사 and the fs_div split; fast)"New value: +"Skip 원문 parsing (structured JSON APIs only — omits 실사, the fs_div split, and fees.headcount, which comes from the 실사 source; fast)"
  3. Changed3 schema fields changed
    • changedInput schema / properties / light / description
      Previous value: -"원문 미파싱 (JSON API 정형만 — 실사·종속·fs_div 분리 생략, 빠름)"New value: +"Skip 원문 parsing (structured JSON APIs only — omits 실사 and the fs_div split; fast)"
    • changedInput schema / properties / refresh / description
      Previous value: -"캐시 무시하고 강제 재수집"New value: +"Bypass the cache and re-collect"
    • changedInput schema / properties / year / description
      Previous value: -"결산 사업연도(회계연도, fiscal year) — 입력한 숫자가 곧 사업연도=회계연도=결산연도다. 빼지 말고 그대로 넣는다. year 가 선택 입력인 도구만 생략 시 최신 공시 연도를 자동 지정한다(이 도구에서 year 가 required 면 생략 불가 — 실제 사용 연도는 응답 year 필드로 확인).예: 'FY2025'·'2025년 재무제표'·'2025 사업보고서'·'2025 회계연도' → 모두 2025(결산일 2025-12-31). 환산은 사용자가 '○○년에 공시(제출)된 보고서'처럼 공시(제출)연도를 명시한 경우에만 수행: 12월 결산법인은 익년도 3월말까지 공시함.(예: '2026년에 공시된 사업보고서' → 2025). 그 밖에는 항상 입력값은 사업연도=회계연도=결산연도 기준. 상대표현('최근 N개년'·'작년' 등)은 '오늘' 기준 가장 최근 '공시된' 사업연도부터 역순으로 센다: 사업보고서는 결산 후 약 90일 내(12월 결산 법인 → 익년 3월) 공시되므로 4월 이후면 최신=작년, 1~3월이면 최신=재작년. 예: 오늘이 2026-06이면 최신=FY2025 → '최근 5개년'=2021~2025 (2020~2024 아님). 지원 하한 FY2015(OpenDART 정형 API 제공 범위) — 2014 이하는 거부된다. 비12월 결산(3·6·9월) 법인은 최신 사업연도가 달력연도와 같을 수 있다(예: 3월 결산은 7월부터 당해연도)."New value: +"결산 사업연도 (회계연도, fiscal year) — the number you pass IS the 사업연도=회계연도=결산연도. Do NOT subtract it; pass it as-is. Only tools where year is optional auto-select the latest published year when omitted (if year is required in the tool you are calling, it cannot be omitted — confirm the year actually used via the response `year` field).e.g. 'FY2025'·'2025년 재무제표'·'2025 사업보고서'·'2025 회계연도' → all 2025 (결산일 2025-12-31). Convert ONLY when the user explicitly names the 공시(제출)연도, as in '○○년에 공시된 보고서': a 12월 결산법인 files by the end of March of the following year.(e.g. '2026년에 공시된 사업보고서' → 2025). Otherwise the input is ALWAYS on a 사업연도=회계연도=결산연도 basis. Relative expressions ('최근 N개년'·'작년' and the like) count back from the most recent PUBLISHED 사업연도 as of today: a 사업보고서 is filed within about 90 days after 결산 (12월 결산 법인 → March of the following year), so from April the latest is last year, and in Jan~Mar it is the year before last. e.g. if today is 2026-06 the latest is FY2025 → '최근 5개년'=2021~2025 (NOT 2020~2024). Supported floor is FY2015 (the range OpenDART's structured APIs cover) — 2014 and earlier are rejected. A 비12월 결산 (3·6·9월) 법인 may have its latest 사업연도 equal to the calendar year (e.g. a 3월 결산 company from July onward)."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral context beyond them: data_available=false means the filing was not found (not 'confirmed absent'), audit_only=true makes fees structurally absent, 연결/별도 split must be read from kam.by_fs_div rather than kam.topics, applicability.guidance[] must always be read, and auditor rotation/연속연수 are not returned. This is exactly the value-add a description should provide.

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?

Front-loaded with a one-line purpose, then cleanly sectioned into Purpose/Usage/Response/Rules, so an agent can scan to the relevant block. It is dense and long, but the sections carry non-redundant content (units, opinion domain, regime notes) rather than filler.

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

Completeness5/5

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

There is no output schema, so the description carries the return-value burden and does so: it names the fields returned, explains the `_m` (백만원) unit, lists the opinion domain values, and discloses what is deliberately omitted (감사인 교체/연속연수). Combined with the rules on null semantics and cache refresh, an agent has everything needed to call and interpret the result.

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% and the year parameter is documented exhaustively in the schema itself, so the baseline is 3. The description adds intent-to-parameter mapping ('감사인·감사보수만 빠르게' → light=true) and explains what the light flag omits in outcome terms, giving meaning beyond the field definitions.

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 and resource: it returns a one-table summary of external-audit execution details (감사인·감사의견·업무수행이사·감사보수·감사투입시간·실사·외부조회). It explicitly differentiates from siblings by routing full 의견근거·KAM to get_audit_report, ICFR to get_internal_control, 계속기업 to get_going_concern, and 모집단 lists to search_audit_findings. An agent can pick this tool without opening any sibling schema.

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?

Gives concrete when-to-use examples with parameter mappings ('삼성전자 2024 감사보수·비감사보수' → corp/year) and a when-to-use-the-fast-path rule (light=true for 감사인·감사보수만). It also names the alternatives for adjacent needs, so both selection and invocation are covered.

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.

Resources