This server is an MCP interface for Korea's National Law Information Open API, letting you search, retrieve, and export Korean legal materials (statutes, precedents, interpretations, treaties, etc.) as data files or citation records.
Check API connectivity and credentials (law_status) – verifies OC key and round-trip access.
List all supported legal categories (law_targets) – 72 types of legal materials with schemas, quirks, and caveats.
Search legal databases (law_search) – search one category (e.g., current statutes, administrative rules, precedents, constitutional decisions, treaty) with query, page size, max records, and scope controls.
Retrieve full text/body of a single document (law_body) – returns articles, holdings, interpretation summaries, etc., with optional article inclusion, effective-date for eflaw, and character limit.
Batch collect multiple targets × queries (law_collect) – save results as xlsx, csv, json, or sqlite files, with budget control and failure reporting.
Map a record to citation/bibliographic fields (law_citation) – extracts issuer, number, promulgation/effective dates, and institution for use in reference managers.
Export and reuse results – supports xlsx, csv, json, and sqlite output for repeated research data collection.
Reference safety/quirks handled – rejects empty queries, caps display at 500/page, handles XML/HTML quirks, missing bodies, and non-XML sources with warnings.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@law-openapi-mcp search current statutes containing '교육' and export to xlsx"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
📈 사용량 — 최근 14일 조회 0회(고유 0) · 클론 0회(고유 0) · 릴리스 자산 누적 다운로드 0
2026-09-22 자동 갱신 · 전체 이력은
docs/usage.csv. GitHub 트래픽 통계는 14일 창만 제공하므로 이 저장소가 매일 찍어 누적한다.
법제처 국가법령정보 OPEN API(law.go.kr DRF)를 검색·수집하는 MCP 서버 + CLI.
현행법령·행정규칙·자치법규·판례·헌재결정례·행정심판례·법령해석례(법제처 + 부처 39종)· 위원회 결정문·별표서식·조약·법령용어 등 72종을 한 인터페이스로 조회하고, 결과를 xlsx·csv·json·sqlite 로 내보낸다. 연구 자료수집 단계에서 반복 재사용하기 위한 도구다.
자매 저장소: na-openapi-mcp(국회도서관) · nl-openapi-mcp(국립중앙도서관) · kci-openapi-mcp · scienceON-mcp
법령 하나가 문헌 하나다. 조문은 인용할 때의 위치로 넣지, 별도 레코드로 쪼개지 않는다. 「초·중등교육법」은 조문 135개짜리 309KB 문서지만 참고문헌에는 한 줄로 들어간다. 판례는 사건 하나, 법령해석례는 안건 하나, 조약은 조약 하나다.
본문이 필요하면 law_body 로 따로 받는다 — 그때는 조문이 구조로 온다.
Related MCP server: LexLink
OC 하나면 된다. open.law.go.kr 에서 OPEN API 를 신청할 때
가입 이메일의 @ 앞부분을 본인이 지정하는 값이다.
cp .env.example .env # LAW_OC=your_id 를 채운다OC 는 비밀값이 아니다. 요청 URL에 평문으로 실리고 응답의 상세링크에도 그대로 되돌아온다.
그래도 사람마다 값이 다르므로 환경변수로 받는다.
uv sync
uv run law status # 연결 점검
uv run law search --target law --query 교육 # 현행법령 검색
uv run law body --target law --id 209959 # 본문 조회
uv run law collect --target law,prec --query 교육,평생교육 --format xlsxMCP 등록:
{
"mcpServers": {
"law": {
"command": "uvx",
"args": ["law-openapi-mcp"],
"env": { "LAW_OC": "your_id" }
}
}
}도구 | 하는 일 |
|
|
| 다룰 수 있는 갈래와 갈래별 실측 스키마·주의사항 |
| 목록 검색. |
| 식별자 1건의 본문(조문·판시사항·질의요지 등) |
| 갈래 × 검색어 조합을 모아 xlsx/csv/json/sqlite 로 저장 |
| 레코드를 서지 필드(발령주체·호·시행일·제정기관)로 매핑 |
무리 | 종수 | 보기 |
법령·규칙 | 7 |
|
판례·재결 | 3 |
|
법령해석 | 40 |
|
위원회 결정문 | 12 |
|
특별행정심판 | 4 |
|
별표·서식 | 3 |
|
조약·용어 | 2 |
|
그 밖 | 1 |
|
전체 목록과 갈래별 실측 스키마는 law targets / law_targets,
무엇이 있는지의 지도는 docs/DRF_CATALOG.md.
본문이 XML 로 오지 않는 4종: licbyl·ordinbyl(별표·서식은 파일 — 목록의
별표서식파일링크·별표서식PDF파일링크 가 원문) · moefCgmExpc·ntsCgmExpc(목록만).
호출 전에 막고 대신 무엇을 보라고 알려 준다.
lsHistory(법령 연혁)·couseLs(관련법령)는 type=XML 을 무시하고 HTML 을 돌려주므로
이 서버는 다루지 않는다. 호출하면 그 사실을 알려 준다.
🔴 모든 실패가 HTTP 200 이다. 없는 target 은 0바이트, 잘못된 OC 는 <Response>,
없는 식별자는 <Law>일치하는 … 없습니다</Law>. 상태코드로는 아무것도 알 수 없다.
🔴 query 를 빼면 전체 카탈로그가 온다 — 오류가 아니다(현행법령 5,614건).
이 서버는 빈 검색어를 거부한다.
🔴 판례 본문은 데이터출처에 따라 없다. 데이터출처명=대법원 은 본문이 오고,
국세법령정보시스템 은 목록에만 있고 본문 조회에 "일치하는 판례가 없습니다" 가 온다.
결손으로 기록하고 넘어갈 일이지 오류가 아니다.
display 상한은 500(1000을 요청하면 500으로 깎이고 numOfRows 에 정직하게 에코된다).
page 에는 하드 상한이 없다 — totalCnt 전량을 회수할 수 있다.
갈래마다 루트 태그·레코드 태그·식별자 파라미터가 전부 다르고 이름에서 유추할 수 없다.
전수 실측 62종 중 45종이 제 이름이 아닌 레코드 태그를 쓴다(부처 해석 39종은 전부
<cgmExpc>, ordin·lsStmd 는 <law>, school 은 <admrul>). 식별자 파라미터도
ID/MST 만이 아니다 — lstrm 은 trmSeqs.
⚠️ totalCnt=0 은 target 이 무효라는 뜻이 아니다 — 검색어가 안 맞은 것일 뿐이다.
자세한 근거와 재현 방법은 docs/LAW_API_GUIDE.md.
MIT
식별자 1건의 본문을 받는다(조문·판시사항·질의요지 등).
Args:
target: 갈래 코드.
doc_id: 목록 결과의 일련번호. 갈래마다 파라미터명이 MST/ID 로 다르지만
이 도구가 알아서 맞춘다.
include_articles: 조문 목록을 함께 돌려줄지(법령·자치법규에만 있다).
ef_date: 시행일법령(eflaw) 전용 — 목록의 시행일자. 🔴 없이 부르면 오류가
아니라 HTML 이 온다. 같은 법령의 시행일별 판본이라 (MST, efYd) 가 신원이다.
max_chars: 본문 텍스트 상한. 넘으면 잘라내고 그 사실을 알린다.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| target | Yes | ||
| ef_date | No | ||
| max_chars | No | ||
| include_articles | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true in annotations, the description discloses several non-obvious behaviors: calling without ef_date returns HTML rather than an error, max_chars truncates the body and notifies the caller, and the parameter-name normalization (MST/ID) is handled internally. These are exact, actionable traits that an agent would otherwise only discover by running the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A one-sentence summary followed by a tight bulleted argument list. Every bullet provides real information, the 🔴 emoji highlights the critical ef_date pitfall, and there is no filler. The structure is easy to scan and front-loads the most important facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for invocation: all parameters are explained, edge cases are flagged, and the read-only behavior is implicit. It lacks a clear statement of the return format (HTML vs JSON) and does not explicitly instruct the agent to use law_targets for target codes, which are the main remaining gaps given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains all five params with roles and conditions, including the ef_date warning and the include_articles scope. The only notable gap is target, which is simply 'branch code' with no enumeration or pointer to law_targets, leaving possible valid values unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: it retrieves the body (본문) of a single identifier, listing example content types (조문, 판시사항, 질의요지). The singular '1건' and the verb '받는다' establish a distinct action from siblings like law_search, law_collect, or law_status. No ambiguity about the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong conditional context for when parameters apply: doc_id is described as a 'list result' serial number, ef_date is 'eflaw 전용', and include_articles is restricted to laws/autonomous regulations. However, it never explicitly names alternative tools or says when not to use this tool, so it lacks the full when/when-not guidance of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한 건을 서지(인용) 필드로 매핑한다 — 발령주체·호·공포일·시행일·제정기관.
목록에서 1건을 다시 찾아 매핑한다. 서지관리 도구(Ibis 의 legislation 유형 등)로
바로 넘길 수 있는 모양이다.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint and openWorldHint, and the description does not contradict these. However, the description adds no detail about side effects or behavioral constraints beyond what the annotations already state, so the score is average due to the lower bar set by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured and unclear, with ambiguous phrasing and a confusing second sentence. It lacks a clear, organized statement of function and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no description of return format or expected result. The mapping behavior is not fully specified, leaving the agent uncertain about what the tool actually produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the meaning or role of the 'target' and 'doc_id' parameters. This is a critical gap for an agent to use the tool effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it maps a single item to bibliographic fields and then finds one from a list, but the exact purpose and input/output semantics are vague. It does not clearly distinguish itself from sibling tools like law_search or law_body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The sibling tool names provide hints, but the description does not explain the conditions or context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
갈래 × 검색어의 합집합을 모아 파일로 저장한다.
⚠️ max_records 는 전체에 걸친 예산이다. 앞선 축이 다 쓰면 뒤 축은 조회되지
않으며, 그 사실은 meta 의 stopped_early_note 로 보고된다.
⚠️ 한 축이 실패해도 나머지는 계속 수집한다 — 실패는 failed_axes 로 보고된다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | law_collect | |
| scope | No | ||
| formats | No | ||
| out_dir | Yes | ||
| queries | Yes | ||
| targets | Yes | ||
| page_size | No | ||
| max_records | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds high-value non-obvious behavior beyond the annotations: max_records is a global budget across all axes, early exhaustion is reported via stopped_early_note, and partial axis failures still continue and are reported via failed_axes. These warnings meaningfully inform the agent about failure modes and resource limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a one-sentence purpose first, then two warning lines. Every sentence carries distinct information, with key behavioral warnings front-loaded in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 3 required, no output schema, and zero schema descriptions, this description is incomplete. It covers important behavioral traits but omits most parameter semantics, output file structure, and return/meta details, leaving the agent without enough information to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains max_records and vaguely references 'axes' for targets/queries. Required out_dir and other parameters like page_size, formats, and scope are left completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource: 'collects the union of 갈래 × 검색어 and saves to a file', which distinguishes it from sibling search/status/body/citation tools by emphasizing batch collection and file output. However, the terms '갈래' and '검색어' are jargon that the reader must infer map to 'targets' and 'queries'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk collection across target/query combinations and saving to a file, but it never explicitly says when to choose law_collect over siblings like law_search or law_targets. No exclusion criteria or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
법령·판례 등 한 갈래를 검색한다.
Args:
target: 갈래 코드. law(현행법령)·admrul(행정규칙)·ordin(자치법규)·prec(판례)·
detc(헌재결정례)·expc(법령해석례)·trty(조약)·eflaw·elaw·lsStmd.
law_targets 로 전체 목록을 볼 수 있다.
query: 검색어. 비울 수 없다 — 비우면 전체 카탈로그가 온다.
max_records: 회수 상한(예산). 이 API 는 page 상한이 없어 올리면 전량도 받는다.
page_size: 한 페이지 건수(최대 500).
scope: 1=제목만(기본), 2=본문 포함.
allow_full_catalog: query="*" 로 갈래 전체를 받겠다고 명시할 때만 True.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| scope | No | ||
| target | Yes | ||
| page_size | No | ||
| max_records | No | ||
| allow_full_catalog | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and openWorldHint annotations, the description adds crucial behavioral context: query cannot be empty or it returns the entire catalog, max_records has no upper bound and can fetch everything, page_size caps at 500, and allow_full_catalog only works with query="*". These are non-obvious behaviors an agent must know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a compact Args list where every line adds value. It is longer than a one-liner but justified by needing to document 6 parameters and several hidden constraints; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter search tool with no output schema, the description covers target codes, query constraints, pagination, scoping, and the full-catalog escape hatch. It leaves a few opaque target abbreviations (eflaw, elaw, lsStmd) undeclared, but compensates by referencing law_targets. The lack of any return-type description is a minor gap given the tool's straightforward search nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it excels. Every parameter is explained with valid values, defaults, constraints, and cross-parameter relationships — e.g., allow_full_catalog requires query="*", and target values are enumerated with real code examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '법령·판례 등 한 갈래를 검색한다' — a specific verb (search) applied to a resource (one branch of statutes/precedents). It lists the exact target codes and scope options, making it unmistakably distinct from sibling tools like law_status or law_body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use the tool (searching a single branch), and it points to law_targets for the full target list, which helps agent routing. It does not explicitly name alternative sibling tools or say when not to use this tool, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
연결 점검 — OC 보유 여부 + 법제처 OPEN API 실제 왕복 1회.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool makes a real network round trip to an external API and checks for OC ownership, which adds behavioral context beyond the annotations. The annotations already declare readOnlyHint=true (safe read-only operation) and openWorldHint=true, so the description complements rather than contradicts them. It does not detail error handling or side effects, but for a health-check tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose (connection check) and specifies the two key behaviors. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a health-check tool with no parameters and no output schema, the description covers the essential action but omits what the agent should expect as a return value (e.g., success/failure, status message). Given the simplicity, this is a minor gap, but the description could be more helpful by stating the expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description need not explain parameter semantics; it correctly focuses on the action. Nothing is missing in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a connection check that verifies OC ownership and performs one actual round trip to the National Law Information Center OPEN API. It specifies a concrete action and resource, distinguishing it from sibling tools that handle search, body, collect, and citation operations. However, it does not explicitly name or differentiate from siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the alternatives. The description only states what it does, not the context in which an agent should invoke it (e.g., before other law tools to verify connectivity). No exclusions or alternatives are mentioned, leaving the usage decision entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
다룰 수 있는 갈래와 갈래별 실측 스키마·주의사항.
갈래마다 응답 태그와 식별자 파라미터가 다르고 이름에서 유추할 수 없다 — 이 도구가 그 표다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context: response tags and identifier parameters vary by genre, and the tool is essentially a static table. It still does not describe the exact output structure or size, but with zero parameters and read-only semantics the burden is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy; the first line front-loads the core purpose, and the second explains why the tool exists. The bold emphasis on not inferring from names is purposeful and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference tool, the description covers the key content areas: supported genres, per-genre schemas, cautions, response tags, and identifier parameters. It could mention how the table should be used with sibling tools, but the sibling list and implied routing make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema has no properties, so the baseline is 4 and there is nothing for the description to compensate for. The description also correctly focuses on the tool's role rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a reference table listing supported genres ('갈래') with their actual schemas and cautions. It distinguishes itself from action-oriented siblings by framing itself as a lookup/metadata tool, though it does not explicitly enumerate which sibling tools it supports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when an agent needs per-genre schemas, response tags, or identifier parameters and cannot infer them from names. However, it does not explicitly state when-not-to-use or name alternatives, so guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0law_bodylaw_citationlaw_collectlaw_searchlaw_statuslaw_targetsScored across 6 tools
Each tool has a distinct role: connectivity check, schema map, single-target search, document body retrieval, bulk collection, and citation mapping. Overlapping actions such as search vs. collect are clearly differentiated by single-result versus multi-axis file output.
All tools follow a uniform law_ prefix with short, lowercase, predictable names. Some names are nouns and some are verbs, but the pattern is consistent and easy to infer.
Six tools cover the full workflow without redundancy: verify, discover, search, retrieve, collect, and cite. The count is well within the ideal range for a focused API wrapper.
The set supports a complete read-only workflow for legal documents: discovering targets, querying, fetching full bodies, bulk collection, and citation export. No obvious missing operation would prevent an agent from accomplishing the core domain tasks.
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Find official Korean public datasets, agency-site menus, disclosure listings, and source URLs.
Korean government open data - weather, population, law search via data.go.kr
Korean business registry, corporate info, parcel tracking, validation APIs