Click on "Install 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., "@korea-onegov-mcp Search for press releases about renewable energy"
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.
OneGov — 대한민국 중앙행정기관 약 50곳의 보도자료·정책·법령·통계·정보공개·고시공고 약 9만 건을 모아 색인한 통합검색 서비스 — 의 공개 API를 감싼 MCP 서버입니다.
사이트에 직접 들어가지 않고 Claude(웹/데스크톱/Code), ChatGPT(개발자 모드), Cursor 등에서 대화로 정부 자료를 검색·조회할 수 있습니다.
원격(Streamable HTTP) 과 로컬(stdio) 두 방식을 하나의 코드베이스로 지원합니다.
빌드 단계가 없습니다. 순수 ESM JavaScript라 git push 하면 Vercel이 그대로 배포합니다.
인증 키가 필요 없습니다. OneGov API가 무인증 공개 API이기 때문입니다.
⚠️ OneGov는 정부 공식 사이트가 아니라 공개자료를 모아 색인한 비공식 검색 서비스입니다. 자료 대부분에 공공누리(KOGL) 조건이 적용되므로, 인용·재사용할 때는 기관명과 원문 링크(source_url) 를 반드시 함께 표기하세요. 이 서버는 모든 응답 하단에 해당 안내를 자동으로 붙입니다.
도구 | 하는 일 |
| 통합검색. 문서유형·기관·지역·법령·발행일 범위·정렬·검색모드 전체 필터 지원 |
| 문서 id로 전문 + 첨부 + 관련법령 + 연관문서 조회 |
| 실제 색인된 검색어 자동완성 (0건 나올 때 먼저 쓰기) |
| 기관코드 목록과 보유 문서 수 ( |
| 공개자료 제목에 자주 등장하는 상위 주제어 |
| 마감임박 지원사업 공고 (D-day·기관 필터) |
| 지원사업·공고 주제 검색 (범위를 미리 좁힌 편의 도구) |
| 특정 부처의 최근 N일 자료를 최신순으로 |
| 검색 → 상위 문서 본문 자동 수집까지 한 번에 (주제 브리핑) |
| ChatGPT 커넥터·딥리서치 규격 호환용 ( |
모든 도구는 읽기 전용이며, response_format 으로 markdown(기본) / json 을 고를 수 있습니다.
Related MCP server: Korean Bill & Debate MCP
방법 1 — GitHub 경유 (권장)
이 폴더에는 이미 git 저장소가 초기화되어 있고 커밋도 들어 있습니다. 원격만 연결해서 밀어 올리면 됩니다.
윈도우 — 탐색기에서 push-to-github.cmd 를 더블클릭하거나, 명령 프롬프트에서:
push-to-github.cmdgit·GitHub CLI가 없으면 스크립트가 winget으로 설치할지 물어보고, GitHub 로그인까지 안내한 뒤 저장소 생성과 푸시를 진행합니다.
(윈도우 CMD에는 bash 가 없으므로 bash push-to-github.sh 는 동작하지 않습니다.)
macOS / Linux
cd korea-onegov-mcp
bash push-to-github.sh수동으로 하려면 — github.com/new 에서 빈 저장소(README·라이선스 체크 해제)를 만든 뒤:
git remote add origin https://github.com/<사용자명>/korea-onegov-mcp.git
git push -u origin main그다음 vercel.com/new 에서 해당 저장소를 Import 합니다.
3. Framework Preset은 Other, 나머지 설정은 손대지 않고 Deploy.
4. 배포가 끝나면 https://<프로젝트명>.vercel.app 주소가 나옵니다.
방법 2 — CLI
npm i -g vercel
cd korea-onegov-mcp
vercel --prodcurl https://<프로젝트명>.vercel.app/mcp
# {"server":"korea-onegov-mcp-server","version":"1.0.0", ...} 가 나오면 정상
# 도구 목록까지 확인
curl -X POST https://<프로젝트명>.vercel.app/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'MCP 접속 주소는 https://<프로젝트명>.vercel.app/mcp 입니다. (/api/mcp 도 동일하게 동작합니다.)
Claude 설정 → Connectors
+ Add custom connector
이름: OneGov 정부자료, URL: https://<프로젝트명>.vercel.app/mcp
Add → 대화창의 도구 아이콘에서 켜고 사용
인증 설정은 비워 두면 됩니다(무인증 서버).
ChatGPT의 커스텀 MCP 커넥터는 개발자 모드가 필요하며 Pro/Team/Enterprise/Edu 플랜에서 제공됩니다.
설정 → Connectors → Advanced → Developer mode 켜기
Connectors → Create
이름과 서버 URL(https://<프로젝트명>.vercel.app/mcp) 입력, 인증은 No authentication
신뢰 확인에 체크하고 생성
이 서버는 딥리서치 규격에 맞춘 search / fetch 도구를 함께 제공하므로 딥리서치 커넥터로도 붙습니다.
cd korea-onegov-mcp
npm install
node src/index.js --helpclaude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\) 에 추가:
{
"mcpServers": {
"korea-onegov": {
"command": "node",
"args": ["/절대/경로/korea-onegov-mcp/src/index.js"]
}
}
}claude mcp add korea-onegov -- node /절대/경로/korea-onegov-mcp/src/index.jsnpm run http # http://127.0.0.1:3000/mcp
npm run inspect # MCP Inspector로 도구 직접 호출해 보기이름 | 기본값 | 설명 |
|
| 로컬 HTTP 모드 포트 |
|
| 로컬 HTTP 모드 바인딩 주소 |
|
| OneGov API 베이스 URL |
|
| 외부 API 타임아웃 |
| (켜짐) |
|
npm run smoke # HTTP 모드로 띄우고 실제 API까지 20개 항목 검증
node scripts/stdio-test.js # stdio 모드 연결 + 주제 브리핑 도구 확인korea-onegov-mcp/
├── api/mcp.js Vercel 서버리스 함수(원격 MCP 엔드포인트)
├── src/
│ ├── index.js 실행 진입점 (stdio / 로컬 HTTP)
│ ├── server.js McpServer 생성 + 사용 지침
│ ├── tools.js 도구 11개 정의
│ ├── client.js OneGov API 클라이언트 + 에러 매핑
│ ├── format.js 마크다운/JSON 포매팅, 길이 제한
│ └── constants.js 상수
├── scripts/ 스모크 테스트
├── public/index.html 배포 확인용 안내 페이지
└── vercel.json 함수 설정 + /mcp 리라이트레이트리밋: OneGov API는 IP 단위 제한이 있어 429가 날 수 있습니다. 서버는 429를 만나면 재시도 안내가 담긴 에러 메시지를 돌려줍니다.
응답 길이: 한 응답이 25,000자를 넘으면 잘라내고 "필터를 좁히라"는 안내를 붙입니다.
stateless: Vercel 함수는 요청마다 새 서버 인스턴스를 만드는 stateless Streamable HTTP 모드로 동작합니다. SSE(GET 스트리밍)는 지원하지 않습니다.
원본 서비스 존중: 이 래퍼는 OneGov가 공개한 API를 그대로 호출합니다. 대량 크롤링 용도로 쓰지 마세요.
MIT (이 래퍼 코드에 한함). 검색되는 자료의 저작권·이용조건은 각 소관 기관 및 공공누리 조건을 따릅니다.
ChatGPT 커넥터/딥리서치 규격에 맞춘 문서 조회 도구. search 가 돌려준 id로 전문을 가져온다.
Args: id (string, 필수) Returns: { id, title, text, url, metadata } 를 JSON 문자열로.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | search 가 돌려준 문서 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the return format (id, title, text, url, metadata) as a JSON string, providing behavioral context beyond 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 two clear sentences stating purpose, usage, args, and returns. Front-loaded with the main purpose, no extraneous words.
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 tool with one parameter, the description covers purpose, usage, and return structure. Annotations provide safety context, and the description fills in return fields. Complete for effective selection and invocation.
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?
With 100% schema description coverage, the schema already documents the 'id' parameter. The description's mention of using the search id adds no new meaning, so baseline 3 is appropriate.
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 retrieves full text documents using an id from search, specifying it's for ChatGPT connector/deep research. This distinguishes it from sibling tools like 'search' (which returns ids) and others.
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 explicitly says to use the id returned by search, providing clear context for when to invoke this tool. It lacks explicit exclusions or alternatives but ties directly to the companion search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
접수 마감이 임박한 정부 지원사업·공고를 마감일 순으로 돌려준다. 창업·중소기업·소상공인 지원사업 탐색의 출발점.
Args:
max_dday (number, 0~60, 선택): D-day 상한. 예: 7 이면 일주일 안에 마감하는 것만.
org_contains (string, 선택): 기관명 부분 문자열 필터(예: "중소벤처기업부", "조달청").
limit (number, 1~100, 기본 30)
response_format ('markdown'|'json', 기본 markdown)
Returns: { grants: [{ id, title, org, ministry_name, deadline_at, dday, support_field, apply_target, region, startup_years, source_url, kogl_type }] } dday=0 은 오늘 마감이라는 뜻이다.
Examples:
"이번 주 마감인 지원사업" → max_dday=7
"중기부 지원사업 마감 임박" → org_contains="중소벤처기업부"
조건에 맞는 게 없으면 onegov_find_support_programs 로 넓게 검색할 것.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 건수 | |
| max_dday | No | D-day 상한(일) | |
| org_contains | No | 기관명 부분 문자열 필터 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context like dday=0 meaning today's deadline and explains the return object structure, but the behavioral core is well-covered by 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?
Concisely structured with Korean overview, clear Args/Returns/Examples sections. Every sentence adds value, no redundancy. The length is appropriate for the complexity.
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?
Despite no output schema, the description fully documents the returned fields including meaning of dday, and provides fallback guidance. All necessary context for using the tool correctly is present.
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% with basic descriptions, but the description adds rich semantics: examples for max_dday and org_contains, explanation of limit default and response_format options, and interpretation of dday in the return object. This goes beyond the schema.
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 returns government support projects with imminent deadlines sorted by deadline (마감일 순), and specifies target users (창업·중소기업·소상공인). This distinguishes it from siblings like onegov_find_support_programs which is for broader searches.
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 provides explicit examples for common use cases (e.g., max_dday=7 for this week's deadlines, org_contains for specific ministries) and explicitly advises using onegov_find_support_programs if no matches, giving clear when-to/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
지원사업(category=grant) 과 고시·공고(doc_type=notice) 로 범위를 미리 좁혀 검색하는 편의 도구. "창업 지원금", "소상공인 지원사업" 같은 요청에 바로 쓴다.
onegov_search 에 category=["grant"] 를 매번 넣는 것과 같지만, 필요한 필터만 노출해 실수를 줄인다.
Args:
query (string, 필수): 무엇에 대한 지원사업인지(예: "청년 창업", "수출", "AI").
region (string[], 선택): 지역명(예: ["서울특별시"]). 전국 사업은 "전국".
ministry (string[], 선택): 기관코드.
from / to (YYYY-MM-DD, 선택): 공고 발행일 범위.
include_notices (boolean, 기본 true): 지원사업 분류가 안 붙은 일반 고시·공고까지 함께 볼지 여부.
sort ('relevance'|'date_desc'|'date_asc', 기본 date_desc): 기본은 최신순.
page / size / response_format: onegov_search 와 동일.
Returns: onegov_search 와 동일한 형식.
Examples:
"요즘 나온 청년 창업 지원사업" → query="청년 창업"
"경기도 소상공인 지원" → query="소상공인", region=["경기도"]
마감일 기준으로 급한 것부터 보려면 onegov_deadline_grants 를 먼저 쓸 것.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 발행일 종료(YYYY-MM-DD) | |
| from | No | 발행일 시작(YYYY-MM-DD) | |
| page | No | ||
| size | No | ||
| sort | No | 정렬(기본 최신순) | date_desc |
| query | Yes | 지원사업 주제 | |
| region | No | 지역명 배열 | |
| ministry | No | 기관코드 배열 | |
| include_notices | No | 일반 고시·공고까지 포함할지 여부 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that return format matches onegov_search and explains the include_notices default, but no additional behavioral context beyond what annotations provide.
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?
Description is well-structured with clear sections (purpose, comparison, args, examples) and front-loaded with core purpose. Slightly long but each sentence adds value; no wasted words.
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?
With 10 parameters and no output schema, description covers all parameter explanations, return format (same as onegov_search), and usage context. Examples enhance completeness. No gaps noted.
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 80%, and description adds meaning beyond schema by explaining parameter purpose (e.g., include_notices, sort options with defaults) and providing examples for query and region. Some parameters like page and size are less elaborated but schema covers them.
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?
Description clearly states it's a convenience tool for searching support programs and announcements, explicitly distinguishing it from onegov_search by pre-filtering category and doc_type. Examples illustrate typical usage.
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?
Explicitly says when to use (support program/announcement searches) and compares to onegov_search. Provides an alternative tool (onegov_deadline_grants) for deadline-urgent requests, clearly guiding agent decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
문서 id로 전문(본문)과 첨부·관련법령·연관문서를 가져온다. id는 onegov_search 결과의 id 필드(UUID)다.
Args:
id (string, 필수): 문서 UUID.
max_body_chars (number, 기본 8000, 최대 40000): 본문 최대 길이. 길면 잘리고 안내가 붙는다.
response_format ('markdown'|'json', 기본 markdown)
Returns: markdown: 제목 · 메타(기관/발행일/원문링크/공공누리 유형/관련법령) · 본문 · 첨부 · 연관 문서. json: { id, doc_type, title, summary, body, ministry_name, published_at, source_url, kogl_type, kogl_notice, attachments[], law_ref[], region, links{related_by_law[], same_ministry_recent[]} }
Examples:
검색 후 "이 공고 신청 자격 알려줘" → 해당 결과의 id로 호출
쓰지 말 것: 아직 문서를 특정하지 못했을 때(→ onegov_search 먼저)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 문서 UUID (onegov_search 결과의 id) | |
| max_body_chars | No | 본문 최대 길이 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds key behaviors: body truncation with max_body_chars, response_format options (markdown vs json) with their output details, and return structure. No contradictions with 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?
Well-structured with Args, Returns, and Examples sections. Front-loaded main purpose. Slightly verbose in Returns but each line provides useful detail. Efficient overall.
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?
Given the absence of an output schema, the description thoroughly explains return formats and includes examples. It also covers usage context and constraints, making it complete for agent understanding.
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% with parameter descriptions. The description adds context: id is from onegov_search, max_body_chars truncation behavior and limits, response_format differences. This adds meaningful detail beyond the schema, justifying a 4.
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 retrieves full text, attachments, related laws, and related documents by document ID. It explicitly links the ID to onegov_search results, distinguishing it from sibling tools like onegov_search and search.
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?
Provides explicit when-to-use: after onegov_search with a specific document ID. Also includes a 'do not use' example: when document has not been identified yet, directing to onegov_search first. This gives clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
색인된 중앙행정기관 목록과 각 기관의 보유 문서 수를 돌려준다. onegov_search 의 ministry 필터에 넣을 코드를 여기서 얻는다.
Args:
name_contains (string, 선택): 기관명에 포함된 글자로 필터(예: "고용", "국토").
response_format ('markdown'|'json', 기본 markdown)
Returns: { ministries: [{ ministry_code, name, org_type, parent_code, doc_count }] } 참고: "_AGGREGATE"는 특정 부처가 아니라 K-Startup 등 집계 포털에서 모은 전 기관 공통 자료다(가장 문서가 많다).
Examples:
"국토교통부 코드가 뭐야" → name_contains="국토" → MOLIT
"어느 부처 자료가 제일 많아" → 전체 조회
| Name | Required | Description | Default |
|---|---|---|---|
| name_contains | No | 기관명 부분 문자열 필터 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds return structure, note about '_AGGREGATE' being aggregated data, and that the tool is for getting codes, providing valuable context beyond 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 concise and well-structured: purpose, args, returns, note, examples. Every sentence adds value with no fluff.
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?
Given the tool's simplicity (2 optional params, no output schema), the description fully covers the return structure, special cases like '_AGGREGATE', and provides examples. Annotations cover safety traits.
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 meaning by explaining the name_contains filter with examples and clarifying the response_format options and defaults.
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 that the tool returns a list of ministries with document counts, specifically for obtaining codes to use in the onegov_search filter. This distinguishes it from siblings like onegov_search or onegov_ministry_latest.
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 explains that the tool provides codes for the ministry filter in onegov_search, with examples. While it lacks explicit when-not-to-use guidance, the context is clear and the examples help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한 부처(또는 여러 부처)의 최신 공개자료를 발행일 역순으로 가져온다. "국토부 요즘 뭐 냈어?" 같은 질문에 쓴다.
Args:
ministry (string[], 필수): 기관코드 배열(예: ["MOLIT"]). 코드는 onegov_list_ministries 로 확인.
doc_type (string[], 선택): 특정 유형만(예: ["press_release"]).
query (string, 선택): 부처 내에서 다시 좁힐 검색어.
days (number, 1~365, 선택): 최근 N일로 제한. 지정하면 from 을 자동 계산한다.
size (number, 1~50, 기본 20) / page (number, 기본 1)
response_format ('markdown'|'json', 기본 markdown)
Returns: onegov_search 와 동일한 형식(항상 최신순 정렬).
Examples:
"국토부 최근 보도자료" → ministry=["MOLIT"], doc_type=["press_release"], days=30
"중기부가 이번 달 낸 공고" → ministry=["MSS"], doc_type=["notice"], days=30
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 최근 N일로 제한 | |
| page | No | ||
| size | No | ||
| query | No | 부처 내 추가 검색어 | |
| doc_type | No | 문서유형 필터(여러 개 가능). press_release=보도자료, policy=정책, law=법령, statistic=통계, info_disclosure=정보공개, faq=자주묻는질문, notice=고시·공고 | |
| ministry | Yes | 기관코드 배열(필수) | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral information: returns latest items by date, supports pagination and response format selection, and mentions sorting. This adds value beyond 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 well-structured with Args, Returns, and Examples sections. It is concise yet informative, with no redundant sentences. Every sentence adds value.
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?
Given 7 parameters and no output schema, the description explains the return format (same as onegov_search, sorted by date) and response format options. It is sufficiently complete for the tool's purpose, though could mention error handling.
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 71%. The description provides additional context for parameters: ministry example code, doc_type list, days range, and examples mapping queries to parameters. This compensates for the uncovered parameters and adds meaning.
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 fetches the latest public documents from one or more ministries, sorted by publish date descending. It provides a concrete use case example ('국토부 요즘 뭐 냈어?') and distinguishes from siblings like onegov_search by focusing on 'latest' from specific ministries.
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 provides clear context for when to use the tool with examples and parameter details. It does not explicitly state when not to use it or mention alternatives, but the examples effectively guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
한 주제에 대해 검색을 돌린 뒤, 상위 문서 몇 건의 본문까지 자동으로 받아와 한 번에 돌려준다. "이 주제 정부 자료 정리해줘" 같은 요청에서 검색→전문조회 왕복을 줄여 준다.
Args:
query (string, 필수): 조사할 주제.
depth (number, 1~5, 기본 3): 본문까지 받아올 상위 문서 수. 많을수록 느리고 응답이 길다.
doc_type (string[], 선택) / ministry (string[], 선택) / from / to: onegov_search 와 동일한 필터.
chars_per_doc (number, 1000~10000, 기본 3000): 문서당 본문 길이 상한.
response_format ('markdown'|'json', 기본 markdown)
Returns: markdown: 검색 요약(총 건수·상위 목록) + 상위 depth 건의 본문 발췌(기관·발행일·원문링크 포함). json: { query, total, candidates[], documents[] }
Examples:
"AI 기본법 관련 정부 자료 정리해줘" → query="인공지능 기본법", depth=3
단순히 목록만 필요하면 onegov_search 를 쓸 것(더 빠르다).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 발행일 종료(YYYY-MM-DD) | |
| from | No | 발행일 시작(YYYY-MM-DD) | |
| depth | No | 본문까지 받아올 문서 수 | |
| query | Yes | 조사할 주제 | |
| doc_type | No | 문서유형 필터(여러 개 가능). press_release=보도자료, policy=정책, law=법령, statistic=통계, info_disclosure=정보공개, faq=자주묻는질문, notice=고시·공고 | |
| ministry | No | 기관코드 배열 | |
| chars_per_doc | No | 문서당 본문 길이 상한 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it mentions the performance trade-off of depth (more documents = slower, longer response), the automatic fetching of full text, and the output format details (markdown vs json). No contradictions are present.
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 well-structured with clear sections (Args, Returns, Examples, usage notes). It front-loads the core purpose and provides necessary detail without redundancy. Every sentence adds value, including the comparison to the sibling tool.
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?
Given the absence of an output schema, the description thoroughly explains the return format and content (search summary + top documents with metadata). It covers all 8 parameters (including filters), provides examples, and addresses when to prefer a sibling tool. The tool's complexity is fully addressed.
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. However, the description adds significant extra meaning: it explains that depth controls the number of full-text documents, chars_per_doc limits content length, and response_format offers two modes. It also clarifies that doc_type and ministry filters are shared with onegov_search, providing context beyond the schema.
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 performs a search on a topic and automatically fetches the full text of top documents (depth). It distinguishes from the sibling onegov_search by explicitly noting that onegov_search is faster for simple lists.
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 provides explicit guidance on when to use this tool (for topic briefing with full text) and when to use onegov_search instead (for list-only needs, which is faster). Examples illustrate typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대한민국 중앙행정기관 약 50곳의 보도자료·정책·법령·통계·정보공개·자주묻는질문·고시공고를 한 번에 검색한다(약 9만 건 색인).
부처 이름을 몰라도 자연어로 검색된다. 하이브리드(키워드+의미) 검색이 기본.
Args:
query (string, 선택): 검색어. 비우면 필터 조건만으로 최신 문서를 훑는다. 짧고 일반적인 명사구가 잘 맞는다(예: "청년 월세", "반도체 특별법").
doc_type (string[], 선택): press_release | policy | law | statistic | info_disclosure | faq | notice
ministry (string[], 선택): 기관코드(예: MSS=중소벤처기업부, MOLIT=국토교통부). 코드는 onegov_list_ministries 로 확인.
category (string[], 선택): 콘텐츠 분류. 지원사업은 "grant".
region (string[], 선택): 지역명(예: "서울특별시", "경기도", "전국").
law_ref (string[], 선택): 관련 법령명 정확일치(예: "중소기업창업 지원법").
from / to (YYYY-MM-DD, 선택): 발행일 범위.
sort ('relevance'|'date_desc'|'date_asc', 기본 relevance): 정확도순 / 최신순 / 오래된순.
mode ('hybrid'|'fulltext'|'semantic', 기본 hybrid): 검색 방식.
page (number, 기본 1) / size (number, 1~50, 기본 20): 페이지네이션.
include_facets (boolean, 기본 true): 결과 분포(문서유형·기관·연도·지역·법령) 요약 포함 여부.
response_format ('markdown'|'json', 기본 markdown)
Returns: markdown: 총 건수 + 결과별 제목/유형/기관/발행일/문서 id/원문 링크/요약, 그리고 패싯 요약. json: { query, page, size, total, results[], facets{}, meta{} } — results[i]에 id, doc_type, title, summary, ministry_code, ministry_name, published_at, source_url, kogl_type, law_ref[], region, attachments[], score 포함.
Examples:
"작년에 나온 청년 주거 지원 정책" → query="청년 주거 지원", from="2025-01-01", to="2025-12-31"
"중기부가 낸 창업 공고만" → query="창업", ministry=["MSS"], doc_type=["notice"]
"개인정보보호 관련 법령 최신순" → query="개인정보", doc_type=["law"], sort="date_desc"
쓰지 말 것: 문서 전문이 필요할 때(→ onegov_get_document), 마감임박 지원사업 목록(→ onegov_deadline_grants)
Errors:
잘못된 doc_type/sort 값은 어떤 필드가 틀렸는지 알려준다.
429는 레이트리밋이므로 잠시 후 재시도.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 발행일 종료(YYYY-MM-DD) | |
| from | No | 발행일 시작(YYYY-MM-DD) | |
| mode | No | 검색모드: hybrid(기본)|fulltext|semantic | |
| page | No | 페이지 번호(1부터) | |
| size | No | 페이지당 건수(최대 50) | |
| sort | No | 정렬: relevance(기본)|date_desc|date_asc | |
| query | No | 검색어. 비우면 필터 조건만으로 조회한다. | |
| region | No | 지역명 배열(예: ['서울특별시']). | |
| law_ref | No | 관련 법령명 배열(정확일치). | |
| category | No | 콘텐츠 분류 배열. 지원사업 공고는 'grant'. | |
| doc_type | No | 문서유형 필터(여러 개 가능). press_release=보도자료, policy=정책, law=법령, statistic=통계, info_disclosure=정보공개, faq=자주묻는질문, notice=고시·공고 | |
| ministry | No | 기관코드 배열(예: ['MSS','MOLIT']). onegov_list_ministries 로 코드 확인. | |
| include_facets | No | 결과 분포 요약 포함 여부 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds operational details: index size (~90k), hybrid search, error handling for invalid enums (field-specific error) and rate limits (429 retry). This goes beyond annotations but does not contradict them.
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?
Well-structured with clear sections (Args, Returns, Examples, Errors). Front-loaded with the main purpose. However, it is somewhat lengthy; some sentences could be condensed without losing meaning.
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?
With 14 parameters and no output schema, the description fully documents return formats (markdown with total/results/facets, JSON with detailed fields including score), provides multiple examples, and covers error cases. An AI agent has sufficient context to use the tool 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?
Schema coverage is 100%, but the description adds substantial value: it explains query style ('짧고 일반적인 명사구가 잘 맞는다'), provides Korean names for doc_type, references onegov_list_ministries for ministry codes, gives example values like 'grant' for category, and describes pagination limits. This enriches understanding beyond the schema.
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 it searches across ~50 Korean government agencies' press releases, policies, laws, statistics, etc. It distinguishes from sibling tools like onegov_get_document (full document retrieval) and onegov_deadline_grants (deadline grants).
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?
Explicit examples are given for different use cases (e.g., '청년 주거 지원 정책', '중기부가 낸 창업 공고만'). It also explicitly states when NOT to use (full document → onegov_get_document, deadline grants → onegov_deadline_grants).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
입력한 앞글자로 시작하는, 실제 색인에 존재하는 검색어를 돌려준다. 검색 결과가 0건일 때 정확한 용어를 찾는 용도로 먼저 쓰면 좋다.
Args:
prefix (string, 필수): 앞글자(예: "청년", "반도체").
response_format ('markdown'|'json', 기본 markdown)
Returns: { suggestions: [{ text, doc_type }] }
Examples:
"청년" → 청년도약계좌, 청년월세지원, 청년기본법 …
쓰지 말 것: 실제 문서를 찾을 때(→ onegov_search)
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | Yes | 검색어 앞글자 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context that results are from actual index (not arbitrary), and explains return structure with examples. Annotations already indicate safe, idempotent read.
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 plus structured args/returns/examples. No filler, all lines add value.
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?
Covers purpose, when/not to use, parameter details, return format, and example. No output schema but return structure is explained adequately.
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 description adds real-world context: prefix means 'first characters', response_format defaults, and example usage clarifies expected input.
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?
Description clearly states it returns actual index keywords starting with a given prefix, distinguishing from sibling onegov_search for finding documents.
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?
Explicitly advises use when search results are zero to find correct terms, and warns not to use for finding actual documents (use onegov_search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
공개자료 제목에서 자주 등장하는 상위 키워드와 등장 횟수를 돌려준다. "요즘 정부가 뭘 많이 하나"를 훑거나 검색어 후보를 잡을 때 쓴다.
Args:
limit (number, 1~100, 기본 30)
response_format ('markdown'|'json', 기본 markdown)
Returns: { keywords: [{ text, count, weight }] }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 돌려줄 키워드 수 | |
| response_format | No | 출력 형식. 'markdown'은 사람이 읽기 좋은 요약(기본값), 'json'은 API 원본에 가까운 구조화 데이터. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds that it operates on public data titles and returns keyword counts and weights, and explains the response_format difference, which provides useful behavioral context.
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?
Description is concise with a clear purpose sentence, a use-case sentence, and a structured Args/Returns block. Every sentence is informative without 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 simple read-only tool with full schema coverage and annotations, the description is adequately complete. It specifies the return structure and output formats, though it lacks mentions of failure modes or pagination, which are not critical here.
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 parameters are documented. The description adds extra value by explaining the response_format values in plain language, clarifying that markdown is human-readable and json is structured.
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?
Description clearly states the tool returns top keywords from public data titles with occurrence counts. The use case '요즘 정부가 뭘 많이 하나' helps contextualize its utility compared to siblings like onegov_suggest_keywords.
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?
Description provides explicit context for use: browsing trending topics and selecting search candidates. However, it does not explicitly exclude scenarios or mention sibling tools as alternatives, leaving some differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ChatGPT 커넥터/딥리서치 규격에 맞춘 검색 도구. 대한민국 정부 공개자료를 검색해 {id, title, url} 목록을 돌려준다. 일반적인 MCP 클라이언트에서는 필터가 풍부한 onegov_search 를 쓰는 편이 낫다.
Args: query (string, 필수) Returns: { results: [{ id, title, url }] } 를 JSON 문자열로.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색어 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds that the data source is Korean government public data and return format is a JSON string. No contradictions.
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?
Extremely concise with two short paragraphs and structured Args/Returns. Every sentence adds value. No wasted words.
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?
Given single parameter, lack of output schema, and rich annotations, the description is complete. It explains purpose, return structure, and when to use alternatives. No gaps.
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 description restates the parameter name and required status. Adds no new semantic info beyond the schema's description ('검색어'). Baseline 3 is appropriate.
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?
Description clearly specifies the tool is for searching Korean government public data, returning {id, title, url} list, and distinguishes from the richer-filtered onegov_search. Verb and resource are well-defined.
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?
Explicitly suggests using onegov_search for general MCP clients due to richer filters, providing clear when-to and when-not-to guidance.
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. Dates show when Glama detected each change.
v1.0.0fetchonegov_deadline_grantsonegov_find_support_programsonegov_get_documentonegov_list_ministriesonegov_ministry_latestonegov_research_topiconegov_searchonegov_suggest_keywordsonegov_trending_keywordssearchEach tool has a clearly distinct purpose: general search, document retrieval, keyword suggestions, ministry listing, trending keywords, deadline grants, support program search, ministry latest, research topic, and two connector-specific tools. No overlap that would cause confusion.
Most tools follow a consistent 'onegov_verb_noun' pattern. However, the last two tools ('search' and 'fetch') break this pattern by omitting the prefix, leading to a minor inconsistency.
With 11 tools, the set is well-scoped for the domain of Korean government document search. Each tool provides distinct functionality without being excessive or insufficient.
The tool surface covers the full workflow: searching with filters, retrieving documents, exploring ministries, trending keywords, deadline grants, support programs, and in-depth research. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Find official Korean public datasets, agency-site menus, disclosure listings, and source URLs.
Korean fact-verification tools for AI agents: business registration, address, DART, apt prices, laws
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
Curated Korean AEC expertise for AI agents: KDS·KCS·KS, building law, practice, and the reasoning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/socialkim/korea-onegov-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
