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

TableJSON Schema
NameRequiredDescriptionDefault
corpYes회사명/종목코드/corp_code
yearYes결산 사업연도 (회계연도, 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).
lightNoSkip 원문 parsing (structured JSON APIs only — omits 실사, the fs_div split, and fees.headcount, which comes from the 실사 source; fast)
refreshNoBypass the cache and re-collect

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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)"
  2. 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)."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare a safe read profile (readOnlyHint=true, idempotentHint=true). The description adds substantial context beyond that: data_available=false means the filing was not found (null fields must not be read as 'confirmed absent'), audit_only=true (F 단독공시) means fees are structurally absent rather than a defect, the kam.by_fs_div field routing for 연결/별도 splits, the mandate to ALWAYS read applicability.guidance[] for next-tool routing, and the explicit note that 감사인 교체/연속연수 are NOT returned. It also defines response semantics: fees `_m` suffix = 백만원 and the opinion domain (적정/한정/부적정/의견거절). This is exactly the behavioral nuance annotations cannot carry.

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?

Long, but densely organized into labeled sections ([Purpose], [Usage], [Response], [Rules]) that each carry distinct information — scope routing, call examples, response format, and edge cases. The main purpose is front-loaded in the opening sentence, and the Rules section is terse bullet-style guidance. Every section earns its place; the length is justified by the tool's complexity.

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?

For a complex tool with no output schema, the description carries the full burden of explaining response interpretation and edge cases, and it succeeds: response format (_m suffix, opinion domain), data-availability semantics (data_available=false), structural absence (audit_only=true), field routing (kam.by_fs_div vs kam.topics), next-tool routing (applicability.guidance[]), and explicitly what is NOT returned (auditor change/consecutive years). Nothing an agent needs to call it correctly and interpret results is missing.

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 schema itself is unusually detailed (especially the year parameter covering fiscal-year vs disclosure-year conversion and relative-date counting). The description adds value above the baseline by mapping natural-language queries to parameter values (corp/year/light usage examples) and by explaining the practical trade-off of light=true (fast, omits 실사). That exceeds the baseline-3 for high coverage but doesn't need to compensate for schema gaps.

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 (반환/return), resource (감사 개요/audit profile), and precise scope (감사인·감사의견·업무수행이사·감사보수·감사투입시간·실사수행내역·외부조회 실시여부 summarized in one table). It also names the sibling tools it is not — get_audit_report (full opinion basis, KAM, emphasis text), get_internal_control (ICFR), get_going_concern (going concern quant), search_audit_findings (company lists) — so an agent can differentiate without opening other schemas.

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?

Explicit usage examples map real user queries to parameter values: '"삼성전자 2024 감사보수·비감사보수" → corp="삼성전자", year=2024' and '"재고실사 입회했는지 빠르게만" → corp="…", year=2024, light=true'. Alternatives are named explicitly with routing conditions (full text → get_audit_report, ICFR → get_internal_control, company lists → search_audit_findings). Nothing is left to inference.

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