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., "@korean-notice-mcp compare the 2025 and 2026 HWP notices in my data folder and list the changed requirements"
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.
한국어 | English
작년 공고와 올해 공고를 넣으면, 바뀐 신청조건과 준비할 서류를 원문 근거와 함께 알려주는 MCP 서버입니다.
한국 지자체·공공기관의 모집공고(HWP, HWPX)를 AI 앱(Claude Desktop 등)에서 바로 읽게 해 줍니다. 모든 결과에는 원문 위치와 문서 해시가 붙어, 사람이 원문과 대조할 수 있습니다.
"올해 청년동아리 공고와 작년 공고를 비교해서, 바뀐 신청조건과 내가 준비할 서류를 근거와 함께 알려줘."
위 화면은 실제 공개 공고(장수군 청년동아리 2025 HWP → 2026 HWPX)를 비교한 출력을 그대로 녹화한 것입니다. 1위는 "고유번호증 또는 사업자등록증"이 필수에서 조건부로 바뀐 것, 2위는 신청기간, 3위는 신청 연령 하한이 15세에서 만 18세로 오른 것입니다. 각 항목의 근거 위치를 get_evidence에 넣으면 해당 원문을 다시 확인할 수 있습니다.
공식 MCP 레지스트리에 io.github.RosieOh/korean-notice-mcp로 등록되어 있습니다.
Node.js 22 이상이 필요합니다.
# 가진 공고 두 개를 바로 비교
npx -y korean-notice-mcp compare 2025-공고.hwp 2026-공고.hwpx
# 공고 하나의 제출서류·신청기간만 보기
npx -y korean-notice-mcp checklist 2026-공고.hwpx
# 합성 예시로 MCP 도구 응답(JSON) 확인
npx -y korean-notice-mcp --democlaude_desktop_config.json에 추가합니다. MCP_DATA_DIR에는 공고 파일을 모아 둘 폴더의 절대 경로를 넣으세요. 서버는 이 폴더 안의 파일만 읽습니다.
{
"mcpServers": {
"korean-notice": {
"command": "npx",
"args": ["-y", "korean-notice-mcp"],
"env": { "MCP_DATA_DIR": "C:\\Users\\me\\Documents\\공고" }
}
}
}연결한 뒤 폴더에 2025-공고.hwp, 2026-공고.hwpx를 넣고 AI에게 두 파일을 비교해 달라고 요청하면 됩니다.
Related MCP server: GongMun Doctor MCP
도구 | 하는 일 |
| 제출서류(필수/조건부와 조건 문구), 신청기간, 자격 문단 후보를 근거 위치와 함께 추출 |
| 두 공고 비교. 서류 추가·삭제·필수/조건부 변경과 신청기간 변경을 먼저, 나머지 문구·표 변경을 중요도 순으로 보여줌. 연도만 바뀐 문구는 |
| 본문과 표(행·열·병합)를 원문 위치·해시와 함께 읽기 |
| 같은 해시의 문서에서 근거 위치의 원문을 다시 확인 |
지원 형식은 HWP, HWPX, TXT, MD, CSV입니다. PDF와 스캔 이미지(OCR)는 아직 지원하지 않습니다. 모든 도구는 읽기 전용이고, 외부 네트워크에 접속하지 않습니다.
장수군이 공개한 5개 사업의 2025·2026 공고 10건(HWP 9, HWPX 1)으로 평가했습니다. 규칙은 3쌍으로만 조정했고, 나머지 2쌍은 보류해 두었다가 평가했습니다. 방법과 전체 결과는 benchmarks/README.md에 있습니다.
이전 방식 | 이 버전 | |
제출서류 재현율 / 정밀도 (전체) | 66% / 7% | 92% / 84% |
신청기간 적중 | 0/10 | 10/10 |
중요 변경 34건 중 결과 상위 15개 안 | 4 | 24 |
사용자가 검토할 변경 항목 수 | 1,779 | 403 |
먼저 알아 둘 한계가 있습니다.
보류 세트를 처음 평가했을 때 서류 재현율은 43%였습니다. 처음 보는 표 양식 하나 때문에 한 문서의 서류를 통째로 놓쳤습니다. 원인을 고친 뒤 86%가 됐지만, 이 수치는 블라인드 결과가 아닙니다.
다른 지자체(군산·용인·대전) 3쌍으로 다시 블라인드 평가한 결과: 서류 정밀도는 90%로 유지됐지만 재현율은 47%에 그쳤습니다. 군산 공고에서는 제목 표기("신청서류 (…)", "신청접수 :")를 인식하지 못해 서류와 신청기간을 전혀 찾지 못했습니다. 처음 보는 양식에 약하다는 것이 현재 가장 큰 한계입니다. 자세한 내용은 평가 문서를 보세요.
정답표는 AI가 원문을 대조해 만든 초안이며, 사람이 독립적으로 검수하지 않았습니다. 표본도 한 지자체의 공고뿐입니다.
규칙 기반이라 "구비서류 발급 방법" 같은 참고표를 서류로 읽거나, 제출서류 섹션 밖에 적힌 서류를 놓칠 수 있습니다.
변경의 법적 의미나 신청 자격을 판정하지 않습니다. 신청 전에는 반드시 원문 공고와 담당 부서로 확인하세요.
읽기: HWP는 rhwp(MIT)로 읽습니다. rhwp의 표 API로 셀의 행·열·병합 구조를 복원해, "제출서류 | 내용 | 발급처" 같은 표에서 서류 열과 설명 열을 구분합니다. HWPX는 자체 XML 파서로 읽습니다.
추출: "제출서류", "(접수기간)", "□ 신청대상" 같은 공고 제목 표기로 섹션을 나눕니다. 그 안에서 번호 항목, 괄호 목록, "※ … 경우 … 제출" 같은 주석에서 서류를 찾습니다. "해당자", "택 1", "~인 경우" 같은 표현으로 조건부 여부를 판단합니다.
비교: 줄 단위로 비교한 뒤, 연도만 바뀐 문구는 따로 분리하고 같은 표의 셀 변경은 하나로 묶습니다. 섹션(자격·서류·기간·금액)과 숫자·키워드 변화로 중요도를 매깁니다.
근거 위치는 두 가지입니다. HWP는 rhwp/scanN(rhwp 스캔 순서)이고, 같은 엔진 버전과 같은 문서 해시에서만 재현됩니다. HWPX는 section0/paragraphN 같은 XML 구조 위치입니다.
공고 원문은 저장소에 넣지 않았습니다. 아래 명령은 게시처에서 원문을 내려받고 SHA-256을 대조한 뒤 평가합니다.
git clone https://github.com/RosieOh/korean-notice-mcp && cd korean-notice-mcp
npm install
npm run fetch-corpus # data/raw/에 공고 10건 저장, 해시가 다르면 중단
npm run evaluate
npm testHWP를 AI에서 읽는 도구는 이미 좋은 것이 많습니다. 이 프로젝트는 그 위에서 공고 한 종류를 깊게 다룹니다.
프로젝트 | 잘하는 것 | 이 프로젝트와의 관계 |
HWP·HWPX·PDF·DOCX 파싱, 서식 채우기, 문서 비교(신구대조표) MCP | 범용 문서 파서·비교. 공고의 필수/조건부 서류, 신청기간, 변경 중요도 같은 의미 단위는 다루지 않음. PDF 공고는 kordoc 쪽이 적합 | |
HWP/HWPX 뷰어·편집기(Rust+WASM), 내장 MCP 서버 | 이 프로젝트의 HWP 파싱 엔진( | |
rhwp 기반 HWP 읽기·쓰기·변환 MCP | 범용 HWP 도구. 공고 해석 기능은 없음 | |
나라장터·공공데이터포털 MCP 서버들 | 공고·입찰 검색(API) | 첨부 HWP는 읽지 않음. "검색 → 첨부 내려받기 → 이 서버로 분석"으로 함께 쓰기 좋음 |
이 프로젝트만의 부분은 세 가지입니다.
공고 전용 추출: 제출서류(필수/조건부와 조건 문구)와 신청기간을 뽑습니다.
전년 대비 변경: 연도만 바뀐 문구는 따로 분리하고, 나머지 변경을 중요도 순으로 정렬합니다.
공개 평가: 실제 공고와 정답표로 만든 평가 세트를 함께 공개합니다.
다른 지자체 공고 쌍과 정답표, 특히 사람이 검수한 정답표를 가장 환영합니다. 개인정보가 들어간 실제 신청 서류는 이슈에 첨부하지 마세요. SECURITY.md를 참고하세요.
코드: MIT 라이선스입니다. HWP 파싱에는 @rhwp/core(MIT, Edward Kim)를 사용합니다.
공고 인용 부분은 MIT 대상이 아닙니다. benchmarks/의 정답표·평가 결과와 데모 이미지에는 장수군청 공개 공고의 일부 문구가 연구·평가 목적으로 인용되어 있습니다. 이 인용 부분의 권리는 원 저작자에게 있습니다. 원 게시물에는 공공누리 제4유형(출처표시, 상업적 이용금지, 변경금지)이 표시되어 있습니다. 출처는 benchmarks/sources.json에 있습니다. 공고 원문 파일은 이 저장소와 npm 패키지에 포함하지 않습니다.
상표: "한글", "한컴", "HWP", "HWPX"는 주식회사 한글과컴퓨터의 등록 상표입니다. 이 프로젝트는 한글과컴퓨터와 제휴·후원·승인 관계가 없는 독립 오픈소스 프로젝트입니다.
책임 한계: 이 도구의 결과는 검토용 후보입니다. 신청 자격이나 제출 의무를 확정하지 않으며, 결과를 근거로 한 판단의 책임은 사용자에게 있습니다.
전년도와 올해 공고의 제출서류·신청기간 변화와 주요 변경 문구를 중요도 순으로, 양쪽 원문 근거와 함께 비교합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| after_path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 | |
| before_path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so no contradiction exists. The description adds useful behavioral detail beyond annotations: results are ordered by importance and grounded with excerpts from both original documents, which helps the agent anticipate the output style.
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 single, dense sentence conveys the resource, comparison scope, ordering, and evidence requirement with no filler. The most important subject (comparing previous and current notices) is front-loaded.
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 low-complexity tool with two path parameters and no output schema, the description sufficiently covers what is compared, how results are ordered, and that both original texts serve as evidence. Nothing critical is missing for an agent to select and invoke it correctly.
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 schema only describes each parameter as a relative path under MCP_DATA_DIR. The description adds semantic meaning by mapping before_path to the previous year's notice and after_path to the current year's notice, and by clarifying that both sides are used for comparison and evidence.
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 names a specific verb (비교합니다), a clear resource (전년도와 올해 공고), and the comparison dimensions (제출서류, 신청기간, 주요 변경 문구). It also specifies output ordering by importance and inclusion of original-text evidence, which clearly distinguishes it from read_notice, extract_requirements, and get_evidence.
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 a between-year comparison of notices is needed. However, it does not explicitly state when not to use it or name alternative tools such as read_notice for reading a single notice or extract_requirements for pulling requirements, so some inference is required.
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 |
|---|---|---|---|
| path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by warning that results require review, signaling the extraction output is provisional rather than authoritative. No contradiction exists.
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 concise sentences, each earning its place: the first defines the tool's extraction scope, the second gives a necessary reliability caveat. No filler or repetition.
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 simple one-parameter, read-only extraction tool with robust annotations, the description covers purpose, extraction categories, and the review caveat. The lack of an output schema means return format is unspecified, but the low complexity and clear scope 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?
Schema coverage is 100% and the single 'path' parameter is fully documented as a relative file path under MCP_DATA_DIR. The description adds no parameter details, but the baseline of 3 applies because the schema carries the semantic burden.
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 uses a specific verb ('추출합니다') and names the resource (공고) plus concrete extraction targets: submission documents (required/conditional), application period, qualification candidates, and source evidence. This clearly distinguishes it from sibling tools like read_notice, compare_notices, and get_evidence.
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 no explicit when-to-use guidance, prerequisites, or comparison to alternatives. It implies use on notices requiring structured extraction, but does not tell the agent when to prefer this tool over read_notice or get_evidence.
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 |
|---|---|---|---|
| path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 | |
| sha256 | Yes | ||
| locator | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds some behavioral context by indicating that the tool returns/confirms the original text at a location within a hashed document, but it does not disclose behaviors like missing-location handling, partial matches, or output format.
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, focused sentence with no filler. It front-loads the key constraint (same hash) and the purpose (check original text at a location), making it concise and easy to parse.
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 three required parameters and no output schema, the description is too thin. It does not explain what 'locator' looks like, what the tool returns exactly, or how path and sha256 work together. Since there is no output schema to rely on, the description should carry more of the return-value and parameter-usage burden.
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 only 33%: only 'path' is described, while 'sha256' and 'locator' have no semantic description in the schema. The description implies that 'sha256' is the hash and 'locator' is the location, but it leaves the locator format ambiguous and does not clarify the relationship between 'path' and 'sha256'.
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 identifies a specific action (확인/verify) and resource (원문/original text) within a clearly scoped context: a document identified by the same hash and a given location. This distinguishes it reasonably from siblings like read_notice or compare_notices, though the verb '확인' is somewhat less specific than 'retrieve' or 'get'.
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 use case is implicitly clear: use this tool when you need the original text at a particular location in a document matched by hash. However, there is no explicit guidance on when to prefer this over sibling tools such as read_notice or extract_requirements, and no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공고문(TXT/MD/HWPX/HWP) 텍스트와 표를 원문 위치·해시와 함께 읽습니다. PDF 제외.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds value beyond annotations by disclosing what gets returned (text and tables with original position and hash) and the PDF exclusion, which is meaningful behavioral context. It doesn't detail error behavior for unsupported files, but annotations carry the safety burden.
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 single compact sentence that front-loads the core action, then packs in formats, output characteristics, and the key exclusion with zero wasted words. Every clause 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 one-parameter read tool with strong safety annotations and no output schema, the description covers the essentials: what is read, which formats are supported, what the return contains, and what is excluded. The only notable gaps are error handling for unsupported files and the absence of an output schema, but the description compensates well for the missing output schema by describing return content.
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 100%, so baseline is 3. The description adds value by constraining what the single path parameter should point to — a notice file among TXT/MD/HWPX/HWP formats — and by signaling that PDF paths are invalid. This narrows the parameter's semantic range beyond the schema's generic 'relative file path' description.
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 uses a specific verb ('reads') tied to a concrete resource (announcement notices) and specifies supported formats (TXT/MD/HWPX/HWP), the output shape (text/tables with position and hash), and an explicit exclusion (PDF). This clearly differentiates it from siblings like extract_requirements and compare_notices based on the reading action alone.
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 scope through the supported format list and the explicit 'PDF 제외' (excludes PDF), which tells an agent when not to use it. However, it never names alternatives (extract_requirements, compare_notices, get_evidence) or states when to prefer this tool over them, so routing guidance is 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.2.0compare_noticesextract_requirementsget_evidenceread_noticeScored across 4 tools
Each tool serves a distinct purpose: reading a notice, extracting structured requirements, comparing notices across years, and retrieving evidence by hash/location. No two tools overlap in function, and the descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case: read_notice, extract_requirements, compare_notices, get_evidence. This is predictable and easy to reason about.
With only 4 tools, the server is tightly scoped to the analysis of Korean notices. Each tool is necessary and non-redundant, and the count is appropriate for the domain without feeling sparse or bloated.
The tool set covers the full lifecycle of notice analysis: reading the raw document, extracting key requirements, comparing with previous years, and verifying evidence. There are no obvious gaps for the stated purpose, and the workflow is complete.
자동화하여 HWPX 문서의 로딩, 탐색, 편집, 검증을 한 번에 처리합니다. 문단·표·주석 추가, 텍스트 일괄 치환, 머리말·꼬리말 설정 등 반복 작업을 신속히 수행합니다. 기…
APICK Korean data, OCR, search, conversion, image and video generation, and asynchronous TTS
Compare PDF or Word versions and return source-cited changes ranked by cost, time, or risk.
Document conversion and OCR for AI agents: PDF, Office docs, images to text.