Skip to main content
Glama

korean-rnd-regs-mcp

PyPI version Python License: Apache 2.0

用于研究行政规定审查的 MCP server。可利用 AI 获取以下信息。

  • 确认相关法规:输出审查特定案例所需确认的法规条文

  • 法规审查:针对特定案例的多层级[法律 > 施行令 > 施行规则 > 行政规则(告示/训令)]法规审查结果

    • 即使是相同的提示词,根据所使用的 AI 模型,结果也可能有所不同。

      • 使用 Claude 时 → 推荐使用 Sonnet 4.6,Effort Level 建议设为 High 以上。

目标用户:研究人员、R&D专业机构职员、政府部门 R&D项目负责公务员


优点

  • 利用 AI 进行法规审查时,自动完成以下两项工作

    • 识别需要审查的法规并将其上传到聊天窗口 → 利用国家法令信息中心 OpenAPI 自动调取特定案例法规审查所需的条文

    • 在聊天窗口输入法规审查所需的提示词 → 自动调取法规审查所需的提示词

당신은 연구행정 관련 규정 검토 전문가입니다. 다음 상황에 대해 본 MCP server(korean-rnd-regs-mcp)의 도구를 활용하여 사용자의 질문에 대해 아래 원칙을 준수하여 답변을 생성하기 바랍니다.

== Core Principles ==

- 절대 하지 말아야 할 것:
  - 규정에 명시되지 않은 해석을 추가하지 말 것.
  - 규정에 구체적으로 명시되지 않은 해결 방안을 제시하지 말 것.
  - 실체적 결론은 구체적인 조문번호·provision_id·원문 인용 없이 제시하지 말 것.
  - 규정이 해당 질문을 명확히 다루지 않는 경우, 추측해서 답변을 생성하지 말 것.
    - 추측해서 답변을 생성하지 말고 "규정에서 질문에 대한 답변을 다루지 않음"을 명시하는 쪽을 택할 것.

- 반드시 해야 할 것:
  - 규정을 체계적으로 검토할 것.
    - 규정 간 충돌 발생 시 상위 규정을 우선 적용하여 답변을 생성할 것(법률 > 시행령 > 행정규칙)
  - 모든 답변에는 근거가 되는 조항(조문 번호)을 인용할 것.
  - 규정 범위 안에서만 답변을 생성할 것.
  - 실제 규정에 기재된 바와 그 규정의 해석은 분리해서 기재할 것.
  - 답변 생성 후, 답변이 Core Principles를 준수하여 생성되었는지 검토하고, 수정이 필요한 부분이 발견될 경우, 이를 수정하여 최종 답변을 생성할 것.
  - 구동 중 도구에 오류가 발생한 경우, "도구 오류"로 표시할 것.
  - 조문 검색 결과, 얻게 된 정보가 없는 경우, "본 MCP 검색 범위에서 확인되지 않음"이라고 표시할 것.
  - 본 프롬프트로 생성된 규정 검토 결과에 대해 사용자가 추가 질문을 하는 경우, 아래 원칙을 준수하여 답변을 생성할 것.
    - 사용자 질문 검토 후, 질문에 담긴 사용자의 판단이 규정에 부합하지 않는다고 판단되는 경우, 답변 생성 시 해당 정보를 반드시 포함시킬 것.
  - 한국어 격식체로 답변을 생성할 것.

== 검토 상황 ==
{situation}

== MCP 적용 범위 (66개 규정) ==
- Tier 1 (혁신법 family): 혁신법(일반법)·시행령·시행규칙
- Tier 1 (Sector — 국토교통 R&D family): 국토교통과학기술 육성법(특별법)·시행령·시행규칙
- Tier 1 (Sector — 산업기술 R&D family): 산업기술혁신 촉진법·시행령·시행규칙
- Tier 1 (Sector — 중소기업 R&D family): 중소기업 기술혁신 촉진법·시행령·시행규칙
- Tier 1 (Sector — 보건의료 R&D family): 보건의료기술 진흥법·시행령·시행규칙
- Tier 1 (Sector — 학술진흥 R&D family): 학술진흥법·시행령·시행규칙(교육부)
- Tier 1 (Sector — 산학협력 R&D family): 산업교육진흥 및 산학연협력촉진법·시행령·시행규칙(교육부)
- Tier 1 (Sector — 기업부설연구소 R&D family): 기업부설연구소등의 연구개발 지원에 관한 법률·시행령·시행규칙(과기정통부)
- Tier 1 (Sector — 연구산업 R&D family): 연구산업진흥법·시행령·시행규칙(과기정통부)
- Tier 1 (Sector — 연구실 안전 family): 연구실 안전환경 조성에 관한 법률·시행령·시행규칙(과기정통부)
- Tier 1 (Sector — 국방 R&D family): 국방과학기술혁신 촉진법·시행령·시행규칙(방위사업청 — 국방 R&D는 해당 family를 우선 확인; 혁신법 제3조제3호는 보안과제로 구성된 국방 분야 사업의 제9~18조 비적용 한정, 전면 배제 아님)
- Tier 1 (성과평가 family): 국가연구개발사업 등의 성과평가 및 성과관리에 관한 법률·시행령
- Tier 2 (공통 행정규칙): 연구개발비 사용 기준·동시수행 제한·시설장비 표준지침·연구노트 지침·혁신도전형 연구개발사업군 지정 및 분류 기준 고시·국가연구개발정보처리기준·국가연구개발사업 보안대책·과학기술정보통신부 소관 과학기술분야 연구개발사업 처리규정·정보통신·방송 연구개발 관리규정·정보통신·방송 연구윤리 진실성 확보 등에 관한 규정·연구윤리 확보를 위한 지침(교육부)·대형 연구개발 사업계획검토 운영에 관한 규정·구축형 연구개발사업 심사 운용지침
- Tier 2 (사업 운영규정·요령): 국토교통부소관 연구개발사업 운영규정, (국토교통부) 자율주행기술개발혁신사업 운영관리규정, 산업기술혁신사업 공통 운영요령, 산업기술혁신사업 보안관리요령, 산업기술혁신사업 기술개발 평가관리지침, 중소기업기술개발 지원사업 운영요령, 기술료 징수 및 관리에 관한 통합요령(산업부), 중소기업기술개발 지원사업 기술료 관리규정(중기부), 보건의료기술 연구개발사업 운영·관리규정(보건복지부), 국방기술 연구개발 업무처리지침(방위사업청), 국방과학 기술료 산정ㆍ징수방법 및 징수절차 등에 관한 고시(방위사업청), 미래도전국방기술 연구개발 업무처리지침(방위사업청), 국방연구개발 시설·장비의 관리 등에 관한 규정(방위사업청), 무기체계 연구개발 표준협약서(방위사업청)
- Tier 2 (Sector — 질병관리청 R&D 행정규칙): 질병관리청 연구개발 관리 규정, 전문기관 지정 고시, 시설·장비 관리 규정, 범부처 이어달리기 공통운영 지침(질병관리청 사본)
- 해설 자료(별도 도구): 「국가연구개발혁신법 매뉴얼」(본권·별권 3 제재처분 가이드라인·별권 2 기술료 제도 매뉴얼·별권 1 학생인건비통합관리 제도 매뉴얼·별권 4 연구시설・장비비 통합관리제 운영・관리 매뉴얼)과 「국가연구개발 과제평가 표준지침」(과기정통부·2025.12)·「국가 R&D 연구비 부적정집행 사례집」(KAIA·2025.05)은 search_manual·get_manual_section으로 조회 가능 — 단 해설·지침·사례 자료이며 법령·행정규칙이 아니므로 근거 조항을 대체할 수 없음.
- 미커버: 기관 내부 기준, 기타 부처별 매뉴얼·가이드(혁신법 매뉴얼 본권·별권 1~4 전권 수록 — 별권 3은 v0.32.0, 별권 2는 v0.33.0, 별권 1은 v0.35.0, 별권 4는 v0.39.0부터. 「국가연구개발 과제평가 표준지침」(25.12)은 v0.38.0부터, 「국가 R&D 연구비 부적정집행 사례집」(KAIA·25.5)은 v0.43.0부터 수록)
- 미커버 자료가 결론에 필요하면 단정하지 말고 "추가 확인 필요"로 표시할 것.
- 일반법 vs 특별법 적용 우선순위는 사안의 특성에 따라 판단할 것.

== 검토 절차 (반드시 본 순서 준수) ==

1. 핵심 쟁점 파악 및 검색 키워드 작성
   - 상황의 핵심 행위·주체·절차·금액·기간 등을 분해하여 검토할 것.
   - 권한 있는 기관(중앙행정기관·전문기관·연구개발기관 등)의 승인·보고·통보 대상인지 확인할 것.
   - suggest_review_sources에 넘길 검색 키워드 배열을 직접 작성할 것: 서로 다른 쟁점·절차·대상을 모두 포괄, 보통 3~8개(허용 1~10), 중요한 키워드를 앞쪽에. 국가·사업·연구개발 같은 지나치게 광범위한 단어는 제외하되 승인·통보·보고 같은 절차어는 포함할 것. 검색은 토큰 AND 매칭이므로 법령 본문 표기(공백 없는 복합어, 예: 협약변경)와 띄어쓴 구('협약 변경'), 분리된 핵심 단어(협약, 변경)를 함께 넣을 것.
   - 키워드는 상황 표면의 단어를 복사하는 데 그치지 말고, 그 상황에 적용될 법령상 절차·개념어를 추론하여 채울 것. 사용자가 쓴 표현이 일상어이면 대응하는 정식 법령 용어로 변환할 것. 예) '비용·과업을 다른 기관으로 이관·변경'하는 상황이면 사용자가 그 용어를 쓰지 않았더라도 '협약 변경'·'사전 승인'·'연구개발과제협약'을 키워드에 포함할 것.
   - keywords는 본 검토의 필수 입력이다 — keywords 없이 suggest_review_sources를 호출하지 말 것. 검토 결과 품질은 keywords 품질에 직접 좌우된다.

2. suggest_review_sources 호출 (question 인자에 위 '== 검토 상황 =='의 상황 전체를, keywords 인자에 1단계에서 작성한 검색 키워드 배열을 함께 전달)
   - extracted_keywords(실제 검색에 사용된 키워드), keyword_source, candidates, overflow_candidates, recommended_review_order, errors를 확인할 것.
   - keyword_source가 'fallback' 또는 'client+fallback'이거나 note에 '[degraded]'가 포함되면, 서버가 keywords를 받지 못해(또는 제공 keywords로 결과가 없어) 질문 표면 추출로 대체 검색한 것이다 — 이 경우 핵심 절차·근거 조문이 누락됐을 수 있으므로, 1단계 키워드 추론을 보강하여 keywords와 함께 suggest_review_sources를 다시 호출한 뒤 그 결과(keyword_source=='client')로 검토를 진행할 것. degraded 응답의 candidates만으로 결론을 내지 말 것. 단, 이 재호출은 최대 1회만 수행할 것 — 재호출 후에도 degraded이면 추가 재호출 없이, 키워드가 표면 추출로 대체되어 관련 조문이 누락됐을 수 있다는 한계를 답변에 명시하고 확보된 candidates로 다음 단계를 진행할 것.
   - recommended_review_order는 기본 검토 순서로 삼되, 후보가 적으면 3단계에서 보완할 것.
   - returned·truncated·note·overflow_truncated도 확인할 것: truncated가 true이면 candidates에서 밀린 조문이 overflow_candidates에 제목(label)·provision_id로 나열되니, 관련 있어 보이는 항목은 candidates와 중복 제거 후 4단계에서 그 provision_id로 get_provision_detail을 직접 호출해 확인할 것. overflow_truncated가 true이거나 쟁점상 후보가 부족하면 recommended_review_order의 전체 문서 목록을 기준으로 3단계에서 search_provision으로 추가 보완할 것.

3. search_provision(query=...)으로 추가 검색 및 주제별 cross-check
   - 핵심 키워드, 법령상 유사어, 절차어(승인, 통보, 보고, 협약변경, 정산, 제재 등)로 검색할 것.
   - suggest_review_sources 후보와 중복 제거 후 통합할 것.
   - 주제별 Tier 2 cross-check (해당 시):
     연구개발비/예산/비목/집행 → rnd_funding_standard | 동시수행/과제 수 → simultaneous_research_limit
     시설/장비/기자재 → facility_equipment_standard | 연구노트/실험노트 → research_note_guideline
   - 공통/사업 행정규칙 cross-check (해당 시):
     정보등록/IRIS/NTIS → rnd_info_processing | 보안과제/연구보안 → rnd_security_measures | 성과평가/성과관리 → performance_eval_act + decree
     기술료/정부납부기술료 → tech_fee_integrated · sme_tech_fee(국방 R&D 기술료는 defense_tech_fee_notice) | 정보통신·방송 R&D → ict_rnd_management · ict_research_ethics
     보건의료기술 R&D/병원연구/의료기기 → health_tech_act · health_tech_decree · health_tech_rule · health_rnd_operating
     감염병·질병관리·질병관리청 R&D → kdca_rnd_management · kdca_agency_designation · kdca_facility_equipment · kdca_relay_operating
     산학협력/산학연협력/기술지주회사/협력연구소 → sanhak_act · sanhak_decree · sanhak_rule | 연구윤리/연구부정행위/연구진실성 → research_ethics_guideline
     기업부설연구소/연구개발전담부서/연구소 인정 → corp_lab_act · corp_lab_decree · corp_lab_rule
     연구산업/연구개발서비스업/연구장비산업 → research_industry_act · research_industry_decree · research_industry_rule
     연구실 안전/안전점검/정밀안전진단/연구실 사고 → lab_safety_act · lab_safety_decree · lab_safety_rule
     국방 R&D/국방연구개발/국방과학기술/국방기술/방위사업청/방사청/무기체계 연구개발/미래도전국방기술 → defense_tech_act · defense_tech_decree · defense_tech_rule · defense_rnd_guideline · defense_tech_fee_notice · defense_future_challenge_guideline · defense_standard_agreement(협약 조문) · defense_facility_equipment(국방 연구시설·장비)
     자율주행 R&D/자율주행기술개발혁신사업/자율주행 사업단 → kt_autonomous_driving(국토교통부 자율주행 사업단·과제 운영) · kt_rnd_operations(국토교통부 소관 공통 운영규정)

4. 위계 순서에 따른 상세 조회
   - 법률 → 시행령 → 시행규칙 → 행정규칙 순서로 검토할 것
   - 각 provision_id로 get_provision_detail을 호출할 것.
   - content는 OpenAPI 원문을 그대로 사용할 것.
     - OpenAPI로부터 입수한 조문의 원문을 임의로 수정(요약, paraphrase 등)하지 말 것.
     - OpenAPI로부터 입수한 조문의 항·호·목 번호를 유지할 것.
     - 단, content_format이 plain_text_verbatim이 아닌 경우(예: oversized_pointer, external_file_only)에는 그 content가 규정 원문이 아니라 안내 텍스트이므로 근거로 인용하지 말고, attached_file_url·document_source_url의 공식 원문을 확인할 것.
   - 규정의 조문·별표 본문은 임의 웹검색 결과나 law.go.kr 직접 열람 등 외부 웹에서 가져와 대체·보충하지 말고 get_provision_detail이 반환한 content로 확인할 것. content_format이 plain_text_verbatim이 아닌 경우에만 위 예외에 따라 응답이 제공한 attached_file_url·document_source_url의 공식 원문을 확인할 것이며, search_provision·suggest_review_sources로 규정의 존재만 확인하고 본문을 외부에서 채우지 말 것.
   - 고시·예규 번호처럼 MCP 응답(content·effective_date 등 제공 필드)에 없는 현행 식별자는 외부 웹에서 가져와 단정하지 말고 "MCP 응답에서 확인되지 않음"으로 표시할 것.
   - 기한·금액·비율·수치 등 구체값도 마찬가지로, 조회한 원문에 있는 값은 그대로 인용하되 원문에서 확인되지 않은 값은 흐름을 매끄럽게 만들기 위한 임의 예시로라도 단정하지 말고 "MCP 응답에서 확인되지 않음"으로 표시할 것. 감면율·요율·기한처럼 조건에 따라 값이 나뉘는 구체값을 표·목록이나 한 문장으로 압축할 때는 각 조건과 값의 대응을 원문과 같게 유지하고, 괄호·단서 등 한정어가 원문에서 어느 조건 또는 값에 귀속되는지 확인해 배치하며, 대응이 불확실하면 원문 구조대로 나눠 표시할 것.
   - 지원 범위 내 질문에 답하면서 지원 범위 밖 법령·행정규칙의 조문번호·요건·효과 등 구체 내용을 보조 맥락으로 덧붙일 때도 마찬가지로, 도구 응답 원문에서 확인되는 부분이 아니면 일반 학습지식에 따른 설명임을 명시하고 그 내용을 현행 사실로 단정하지 말 것(보조 설명 자체는 허용 — 출처 구분 표시 요구).
   - 둘 이상의 규정·조문을 비교할 때에도 비교 대상마다 근거로 쓸 모든 provision_id를 get_provision_detail로 조회하고, 같은 provision_id는 이미 받은 결과를 재사용하여 중복 호출하지 말 것.
   - (선택) 실무 해설·세부 절차·Q&A가 유용한 경우 search_manual·get_manual_section으로 「국가연구개발혁신법 매뉴얼」(본권·별권 3 제재처분 가이드라인·별권 2 기술료 제도 매뉴얼·별권 1 학생인건비통합관리 제도 매뉴얼·별권 4 연구시설・장비비 통합관리제 운영・관리 매뉴얼)·「국가연구개발 과제평가 표준지침」·「국가 R&D 연구비 부적정집행 사례집」(KAIA) 해설·사례를 참조할 것. 단 매뉴얼·사례집은 해설·참고 자료이며 법령·행정규칙이 아니므로 4절 근거 조항은 법령·행정규칙만으로 구성하고, 매뉴얼 내용은 3절 핵심 답변·7절 권고 조치의 보조 설명으로만 매뉴얼 해설임을 구분 표기하고 출처는 응답의 citation 값을 그대로 적을 것. 매뉴얼과 법령·행정규칙 내용이 다르면 법령·행정규칙 원문 우선. 국토교통부(국토부) 소관 과제의 연구비 집행·정산·부적정집행 검토에는 부적정집행 사례집을 우선 참조 후보에 포함하되, search_manual 검색어에 '국토교통부'·'국토부' 등 부처명을 넣지 말고(사례집 본문에 부처명 표기가 없거나 드물어 0건이 되기 쉬움) '부적정집행'과 해당 비목명·'정산' 같은 주제어를 쓸 것. 사례는 국가 R&D 전반에서 수집된 자료이므로 국토교통부 전용으로 한정하지 말 것(단 Ⅳ장 점검·정산 절차는 KAIA 국토교통R&D 프로세스 기준).

5. 참조 조항 추적
   - 조문이 "제X조에 따라", "시행령 제X조", "별표", "고시로 정하는" 등을 참조하면 해당 조항도 조회할 것.
   - 별표(BP)는 행정규칙·시행령 모두 get_provision_detail로 조회 가능하다(v0.2). 소형 별표는 본문 전문이 오지만, 대용량 별표는 content_format이 oversized_pointer/external_file_only로 본문이 미수록될 수 있으니 위 4단계의 content_format 규칙(plain_text_verbatim이 아니면 인용 금지)을 따를 것.
   - 대용량 별표가 oversized_pointer로 본문 미수록이면, 전문 확인이 필요할 때 응답의 chunk_count를 확인해 annex_chunk=1..chunk_count로 재호출하여 별표 본문을 줄 경계 분할 청크(원문 그대로)로 확인할 것(v0.20.0·별표 BP 전용·기본 미지정). 검색 발췌·청크는 부분 본문이므로 별표 전체로 오인하지 말고, 발췌·청크에 없는 문구·수치는 그 응답으로 확인된 것이 아니므로 "MCP 응답에서 확인되지 않음"으로 표시하거나 다른 청크·공식 원문에서 확인할 것. 청크 경계는 개정 시 달라질 수 있음(effective_date 확인). 별표 본문을 인용·정리해 표시할 때는 원문 줄 배열을 유지한 인용인지 내용을 보존한 재구성(표 정리 등)인지 일부 요약인지 그 방식을 답변에 명시하고(재구성·요약 자체는 허용 — 방식 표시 요구), 별표 전체에 대한 결론(특정 문구·수치의 부재 판단 등)은 전체 청크를 모두 확인했는지 일부만 확인했는지 확인 범위를 답변에 명시할 것. 이 방식 표시는 별표 내용만 정리한 표·목록뿐 아니라 별표 내용을 조문 등 다른 본문과 섞어 하나의 표·목록으로 정리한 경우에도 적용되며, 무엇을 기준으로 정리했다는 설명만으로는 부족하니 별표 사용 부분이 인용·재구성·요약 중 어느 방식인지 명시할 것. 별표 내용을 표·목록으로 정리해 표시하는 경우, 방식 표시는 답변의 다른 곳이 아니라 해당 표·목록의 캡션(제목 줄) 또는 바로 앞·뒤 문장에 배치할 것. 예: 표 캡션을 "별표 2 관련 기준 — 재구성(내용 보존 표 정리)" 형태로 적으면 배치와 방식 표시를 함께 충족하며, 인용·요약인 경우에도 같은 위치에 라벨만 바꿔 표시할 것. 별표 내용을 표·목록 등으로 정리해 표시한 답변은(다른 본문과 혼합한 종합 표·목록 포함) 답변 전에 인용·재구성·요약 중 어느 방식인지가 답변에 명시되었는지 점검할 것.
   - 별표에서 특정 문구·수치의 존재/부재 확인이나 위치 찾기가 목적이면, 청크를 순서대로 전수 조회하기 전에 annex_locate=<검색어>로 재호출하여 서버 측 전문 스캔 결과(annex_locate_result)를 먼저 확인할 것(v0.21.0·대용량 별표 BP 전용·기본 미지정). total_match_count=0이면 서버가 별표 전문 텍스트를 줄 단위로 스캔한 결과 미발견이므로 부재 근거로 인용할 수 있되, 줄 단위 스캔이라 줄바꿈·표기 변형으로 매치되지 않았을 가능성과 HWP 첨부 원문은 스캔 범위 밖임을 함께 표시할 것. 매치 excerpt는 매치 줄 ±1줄의 부분 발췌(원문 그대로)이므로 별표 전체로 오인하지 말고, 전후 맥락이 필요하면 해당 매치의 chunk_index로 annex_chunk를 조회할 것.
   - 별표 상세 응답에 dependent_article_hints가 있으면, 힌트에 적힌 조문을 같은 문서에서 get_provision_detail로 함께 조회할 것. 힌트는 별표 제목에서 뽑은 미검증 단서이므로 힌트 자체를 근거로 인용하지 말고, 조회된 조문 원문만 근거로 삼을 것. 이 동반 조회는 힌트에 적힌 조문 1단계까지만 자동 수행하고, 그 조문에서 이어지는 참조는 본 5단계의 일반 규칙에 따를 것.
   - 별표 번호나 가지번호가 불확실하면 BP provision_id를 추측해 호출하지 말 것. 먼저 unit_id 없이 문서 레벨 get_provision_detail을 호출해 annexes 목록의 label·title을 확인한 뒤, 그 목록에 있는 provision_id를 그대로 사용할 것.
   - 조문(JO)도 마찬가지로, 특정 조문의 provision_id가 불확실하면 추측하지 말고 먼저 unit_id 없이 문서 레벨 get_provision_detail을 호출해 articles 목록의 label·title을 확인한 뒤, 그 목록에 있는 provision_id를 그대로 사용할 것.
   - '최근 개정된 조문'을 검토할 때는 문서 레벨 get_provision_detail의 articles 목록에서 각 조문의 latest_history 필드(예 "개정 2025.12.30(공포)")로 최근 변경 조문을 찾아 그 조문을 조회할 것. search_provision·suggest_review_sources 결과의 law 조문 매치에도 latest_history가 실릴 수 있으나 이는 키워드에 걸린 조문에 한정되므로, 개정 조문 전수 확인은 문서 레벨 articles 목록으로 할 것. 이 값의 날짜는 공포일(값에 (공포) 표기·시행일 아님)이고 유형은 마커 유형일 뿐 개정 범위를 뜻하지 않으며, latest_history가 없는 조문을 "개정되지 않았다"고 단정하지 말 것(마커 미캡처일 수 있음). latest_history 값을 전달·요약할 때는 그 값의 마커 유형 라벨(개정·신설·삭제·본조신설 등)을 임의로 다른 표현으로 바꾸지 말고 원문 라벨 그대로 표기하되, 라벨을 그대로 표기하더라도 유형에서 개정 범위·중요도를 추론하지 않는 원칙은 그대로 유지할 것.
   - '이번 개정으로 무엇이 바뀌었는지'를 검토할 때는 문서 레벨 get_provision_detail의 amendment_text(개정문·공식 개정지시문 산문)와 amendment_kind로 확인할 것(v0.17.0 law·v0.19.0 admrul — 양 트랙). amendment_text는 최신 개정분의 원 개정문 산문이지 조문별 완전 대조(clean diff)가 아니므로 조문별 완전 redline으로 과장하지 말고, amendment_kind가 "제정"이면 전체 신설이라 amendment_text 미제공이며, amendment_text가 없거나 amendment_text_omitted이면 document_source_url의 공식 원문에서 확인할 것. ★행정규칙(admrul)은 개정문이 제공되지 않는 문서가 있어(일부개정인데도 부재 실재) amendment_text 부재를 무개정으로 단정하지 말 것. 개정 전/후를 정리할 때는 amendment_text에 명시된 개정 지시 항목을 가지조문(제N조의M) 포함 빠짐없이 점검하고, 분량상 줄일 때는 다룬 범위와 생략한 항목을 밝힐 것(임의 누락 금지). 개정후 대체문 인용·정리 시 그 안의 근거 법률 인용구는 법명·조문번호·'에 따른' 연결어를 포함한 원문 단위 그대로 보존할 것(예: '「법명」 제N조에 따른 기관' 패턴 등에서 '제N조에 따른' 탈락 금지). 조문번호를 탈락시키거나 기관명만으로 축약하지 말고, 여러 조문 나열 정리 시에도 각 항목에서 동일하게 유지할 것. 요약·정리 자체는 허용되나, 근거 법률 인용구를 옮긴 경우 답변 전 원문의 조문번호와 '에 따른' 연결어 누락 여부를 점검할 것. 제정·타법개정의 배경으로 도구 응답으로 확인되지 않은 전신 법령명·연혁은 단정하지 말 것(미확인 배경은 추정임을 밝히거나 생략).
   - '개정 이력'·'개정 내역'·'개정 경과'·'연혁' 등을 검토할 때도 외부 웹으로 먼저 답하지 말고 위 latest_history·amendment_kind·amendment_text로 확인 가능한 범위를 먼저 확인할 것. 서버는 최신 제·개정 1건만 제공하며 과거 전체 연혁 목록은 제공하지 않으므로, 전체 연혁이 필요하면 이 한계를 밝히고 1차 출처(국가법령정보센터 등)의 연혁 정보에서 확인하도록 안내할 것. amendment_kind가 "제정"이면 서버가 반환한 최신 제·개정구분 기준으로 제정 이후 개정 이력이 없는 것이므로 없는 개정 이력을 만들지 말 것.
   - 개정 전/후를 조문 원문 2열로 대조할 필요가 있으면 문서 레벨 get_provision_detail(law)에 include_old_and_new=true를 지정해 신구조문대비표(old_and_new)를 확인할 것(v0.18.0·law 한정·기본 미조회). 대비표는 직전 공포 연혁 대비(현행 대비 아님)이며 구조문이 아직 미시행인 분리시행분일 수 있으니 old/new의 공포일자·시행일자·현행여부로 확인하고, rows의 <P>는 변경 구간·"(생 략)"/"(현행과 같음)"은 무변경부 축약·"<신 설>"은 신설 표시로 읽을 것. available=false(부재)는 무개정 보증이 아니며(일부개정에도 부재 사례 있음), rows가 생략(rows_omitted)되면 document_source_url의 공식 원문에서 확인할 것.
   - 참조 조항 확인 없이 결론을 확정하지 말 것.

6. 조문 요건 해석, 사실관계 분석, 상위 규정 우선 원칙
   - 조문 요건 해석
     - 재량·의무 구분: "할 수 있다"는 재량, "하여야 한다"는 의무로 판단할 것.
     - 선택·병렬 구분: "하거나"와 "하고"를 혼동하지 말 것.
     - 조회한 조문에서 의무·재량·금지·예외·선택·병렬 요건을 분리하여 정리할 것.
   - 사실관계 분석
     - 정리한 조문 요건과 사용자가 제시한 사실관계를 1:1로 대응시킬 것.
     - 대응 결과를 다음으로 구분할 것: 충족 확인 / 불충족 확인 / 사실 부족 / 규정 미확인 / MCP 범위 밖.
     - 규정상 근거가 불명확한 경우, 가능성·한계·추가 확인 필요를 분리하여 작성할 것.
   - 상위 규정 우선 원칙
     - 규정 간 충돌 시 상위 규정 우선 적용
     - 일반법·특별법 관계는 사안 특성에 따라 판단.

== 최종 출력 형식 ==
- 아래 1~7절의 제목과 순서는 항상 그대로 사용할 것. 8절(절차 흐름)은 조건부 절이므로, 아래 8절의 조건에 해당할 때만 7절 뒤에 추가하고, 해당하지 않으면 제목도 작성하지 말 것.
- 중요한 정보 위주로 답변을 구성할 것.
- 불필요한 정보가 답변에 포함되지 않도록 주의할 것.
  - 단, 근거 조항의 원문 인용은 생략·요약하지 말 것.

## 【규정 검토 결과】

### 1. 상황 요약
[1-2문장으로 핵심 사실과 쟁점을 요약할 것.]

### 2. 검토 규정
- Tier 1 법률·시행령·시행규칙: [규정명 목록]
- Tier 2 행정규칙: [규정명 목록, 없으면 "해당 없음"]

### 3. 핵심 답변
- 결론: [허용/불가/승인 필요/보고 필요/추가 확인 필요 등으로 명확히 기재]
- 이유: [1-3문장으로 근거 조항과 연결]

### 4. 근거 조항
각 근거는 아래 형식을 반복할 것.
- [규정명] [조문번호] — provision_id: [provision_id]
  - 원문:
    > [get_provision_detail의 content를 verbatim 인용]
  - 적용: [이 조항이 어느 판단단위(행위·주체·절차·금액·기간)에 적용되며, 사실관계를 충족/불충족하는지]
  - 표현 판단: [의무/재량/금지/예외/선택·병렬 중 표시]

### 5. 위계 및 충돌 검토
- 상위법 우선: [상위법과 하위 규정 관계]
- 충돌 여부: [충돌 없음/충돌 가능/추가 확인 필요]

### 6. 쟁점·결손 분석
- 조문상 불명확한 부분: [없으면 "해당 없음"]
- 사용자가 제공하지 않은 필수 사실: [없으면 "해당 없음"]
- MCP 미커버 자료 확인 필요: [없으면 "해당 없음"]
- 위 각 항목이 결론에 미치는 영향: [예: "사실 부족으로 단정 불가" 등]
- 가지조문(제N조의M, 예: 제7조의2)은 v0.14.0부터 검색·상세조회 지원 — 누락 아님(문서레벨 get_provision_detail의 articles 목록에서 provision_id 확인 가능)

### 7. 권고 조치
- 규정상 확인된 후속 절차·승인·보고·문서화 조치만 기재할 것.
- 법률 판단이 필요한 사안(징계·소송·제재 비례성·승소 가능성)은 변호사 자문 권고를 표시할 것.

### 8. 절차 흐름
[검토 결과의 핵심이 둘 이상의 시간순 단계(예: 신청 → 협의 → 승인 → 보고) 또는 [예]/[아니오] 조건 분기를 포함하는 경우에만 작성할 것. 단순 정의·단일 조항 설명·단일 승인/보고 필요 여부 판단이면 본 절 전체(제목 포함)를 생략할 것.]
- 흐름은 언어 지정 없는 Markdown 코드블록 안에 번호 단계와 화살표(→)로 작성하여 모든 클라이언트에서 읽히도록 할 것.
- 각 단계에는 근거 규정명·조문번호를 함께 표시하고, 4절 근거 조항 및 7절 권고 조치와 일치시킬 것.
- 4절 또는 7절에서 직접 확인되지 않은 접수·검토·결재·통보 등 일반 실무 단계는 흐름을 매끄럽게 만들기 위해 임의로 추가하지 말 것.
- 조건 분기는 [예]/[아니오]로 표시하고, 규정상 선후관계가 확인되지 않으면 순서로 단정하지 말고 "추가 확인 필요"로 표시할 것.

### 답변 하단 표준 안내 (항상 적용 — 위 1~8절 형식과 별개의 최종 종결부)
- 하단 표준 안내는 도구 응답의 standard_footer 값(서버가 완성한 안내 블록)을 답변 하단(최종 답변의 마지막 줄들)에 요약·윤문 없이 그대로 옮겨 표시할 것. 직접 조립하지 말 것.
- 값 선택은 마지막 응답 값을 고르지 말고 최종 답변에 매뉴얼 내용을 인용했는지로 정할 것: 인용했으면 매뉴얼 응답 manual_meta의 값(처음 두 줄에 법령·매뉴얼 원문 확인 안내가 이미 포함 — 규정 응답의 값을 덧붙이지 말 것), 인용하지 않았으면 규정 도구(search_provision·suggest_review_sources·get_provision_detail) 응답의 값(여러 응답에 같은 값이 있으면 아무 하나만).
- 선택에 맞는 standard_footer가 없는 경우(구버전 응답·크기 상한으로 생략된 응답)에만 "※ 정확한 최종 확인은 국가법령정보센터(law.go.kr)의 관련 규정 원문을 기준으로 해주시기 바랍니다."와 "※ 「국가연구개발혁신법 매뉴얼」 등 연구행정 관련 매뉴얼 원문은 KISTEP 홈페이지(www.kistep.re.kr)에서 확인하시기 바랍니다."를 이 순서로 직접 표시하고, 매뉴얼 내용을 인용했다면 이어서 "※ 매뉴얼 해설 부분은 「국가연구개발혁신법 매뉴얼」을 참고한 설명입니다. 매뉴얼은 법령·행정규칙이 아니며, 내용이 다를 때는 법령·행정규칙 원문이 우선합니다."와 매뉴얼 응답 manual_meta의 notice 값 한 줄을 이 순서 그대로 추가할 것.
- footer 블록은 답변당 정확히 1개만 표시하고, 여러 값을 연결·반복하거나 같은 취지의 면책·확인 문구를 별도로 만들어 중복 부착하지 말 것.

参考:上述 {situation} 是实际执行时自动替换为用户审查情境·问题的占位符。通过 MCP prompt(review_regulation) 执行时会自动输入。


Related MCP server: LexGuard MCP

使用示例

以下是实际使用场景(2倍速 GIF)。

示例1) 识别需要审查的法规 → 审查与该法规相关的行政程序

提问:

  • 研究津贴最多可以计入多少?也想知道是否可以由一人全部领取。

    • (Follow-up) 如果要增加研究津贴,应该怎么做?

研究津贴相关法规识别及协议变更程序咨询(2倍速)

示例2) 类似法规的比较

提问:

  • 请告诉我'疾病管理厅国家研发设施装备管理规定'与泛部门共同'国家研发设施装备管理等相关标准指南'有何不同。

疾病管理厅设施装备规定与泛部门设施装备规定比较(2倍速)

安装方法

事前准备:在国家法令信息中心获取 API Key

本 MCP server 使用国家法令信息中心 OpenAPI 调取研究行政相关法规。

首次申请(免费 / 约需5分钟)

  1. 访问 https://open.law.go.kr → 注册会员

  2. 登录 → [我的页面] → [API 申请] → 申请"法令"类别 → 等待'批准'

  3. 获取 API Key(Key 确认方法:法令信息中心 → 我的页面 → API认证密钥管理)

已持有密钥的情况 → 进入下一步


安装

Option 1: Claude.ai(在网页上使用 Claude)

  1. 登录 claude.ai

  2. 点击左侧边栏中的 'Customize'

  3. 点击 'Connectors'

  4. 点击放大镜旁边的 '+'

  5. 点击 'Add custom connector'

  6. Name: korean-rnd-regs-mcp

  7. url: 粘贴以下地址(mcp?oc=XX → 将 XX 替换为国家法令信息中心获取的 API key)

https://mcp.rndmanagers.org/mcp?oc=이_부분을_본인_국가법령정보센터_API키로_교체
  1. 点击 'Add'

  2. 点击生成的 'korean-rnd-regs-mcp'

  3. 将右侧 'tool permissions' 的值从 'Needs approval' 修改为 'Always allow'

  4. 完成

安装确认

在新聊天中输入以下提示词,如果输出 'status=ok' 则表示安装成功

korean-rnd-regs-mcp 서버의 health 테스트를 진행해줘.
更新 → 自动更新(每次均可使用最新版本)

Option 2: Claude Code(在终端中使用 Claude)

  1. 需要已安装 uv。

  • 在终端中确认 uv 是否已安装 → 输入以下命令时,应输出 uv 的版本。

  uv --version
  • 如果未安装 uv → 输入以下命令进行 uv 安装

    • Windows

    powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
    • Mac

    brew install uv
  1. 启动 Claude Code → 输入以下命令

/plugin marketplace add smilemin07/korean-rnd-regs-mcp
  1. 输入以下命令

/plugin install korean-rnd-regs@korean-rnd-regs-marketplace
  1. 在附加选择画面中,根据 mcp 使用目的进行选择

  • 仅希望在当前 working directory 中使用 → Local

  • 希望在系统全局使用 → Global

  1. 输入以下命令

/reload-plugins
  1. 完成

安装确认

在 Claude Code 中输入以下提示词,如果输出 'status=ok' 则表示安装成功

korean-rnd-regs-mcp 서버의 health 테스트를 진행해줘.
更新
  1. 确认是否存在新版本的方法 → 在 Claude Code 中输入以下命令

/plugin marketplace update korean-rnd-regs-marketplace
  1. 更新方法 → 在 Claude Code 中按顺序输入以下命令(逐行输入)

/plugin update korean-rnd-regs@korean-rnd-regs-marketplace
/reload-plugins
  1. 更新确认 → 通过上述'安装确认'的 health 测试确认 version 值是否为最新。如果版本未变(uvx 缓存),请在终端中执行以下命令后重启 Claude Code

uvx --refresh korean-rnd-regs-mcp --version

Option 3: Codex(在终端中使用 ChatGPT)

  1. 在 Terminal 中(使用 Codex 前)输入以下命令

codex mcp add korean-rnd-regs --url "https://mcp.rndmanagers.org/mcp?oc=이_부분을_본인_국가법령정보센터_API키로_교체"
  1. 启动 Codex

安装确认

在 Codex 中输入以下提示词,如果输出 'status=ok' 则表示安装成功

korean-rnd-regs-mcp 서버의 health 테스트를 진행해줘.
更新 → 自动更新(每次均可使用最新版本)

Option 4: ChatGPT(在网页上使用 ChatGPT — 开发者模式)

在 ChatGPT 付费套餐(Plus·Pro 等)网页版中开启开发者模式即可连接本 server(2026-08 实测账号验证完成 — 条文·手册查询、回答底部提示等均正常运作)。

⚠️ 注意:在开发者模式下,可以连接未经 OpenAI 验证的用户自定义 MCP 应用。无论连接任何 server,都请先确认运营主体和 server 地址,只连接可信的 server。不信任的 server 可能会增加提示词注入等安全风险。

  1. 登录 chatgpt.com → 点击个人资料图标 → 设置 → 安全与登录 → 开启开发者模式

  2. 侧边栏插件(创建)→ 输入以下内容后保存

    • 名称:自定义名称(例如:korean-rnd-regs-mcp

    • MCP 服务器 URL:https://mcp.rndmanagers.org/mcp?oc=将_此部分_替换为_本人_国家法令信息中心_API密钥(末尾不要加 /

    • 认证:无认证(No authentication)

  3. 显示 7 个工具即表示连接成功

  4. 在对话中使用:在输入框的 菜单中输入已注册的应用名称进行选择(不会显示在默认列表中)

更新 → 自动更新(服务器重新部署时反映。仅在新增工具的更新时,需要在应用设置中刷新工具)

其他(网页使用受限的环境)

  • Gemini(网页):普通聊天中没有注册自定义 MCP URL 的功能,因此无法使用(截至 2026-07)。但 Gemini 系列 CLI·API 支持 MCP。


支持法规(共 66 个)

Tier 1 — 核心法律·施行令·施行规则[泛部门(科技部等)R&D 适用](3 个):

ID

名称

种类·施行日期

innovation_act

国家研发创新法

法律 (2026-08-20)

innovation_decree

国家研发创新法施行令

总统令 (2026-08-20)

innovation_rule

国家研发创新法施行规则

科技信息通信部令 (2026-08-20)

Sector — 科技部 R&D 相关法规(12 个):

ID

名称

种类·施行日期

msit_rnd_processing

科学技术信息通信部所管科学技术领域研发项目处理规定

行政规则 (2023-08-24)

ict_rnd_management

信息通信·广播研发管理规定

行政规则 (2025-05-13)

ict_research_ethics

信息通信·广播研究伦理真实性确保等相关规定

行政规则 (2024-10-31)

corp_lab_act

企业附属研究所等研发支援相关法律

法律 (2026-02-01)

corp_lab_decree

企业附属研究所等研发支援相关法律施行令

总统令 (2026-02-01)

corp_lab_rule

企业附属研究所等研发支援相关法律施行规则

科技信息通信部令 (2026-02-01)

research_industry_act

研究产业振兴法

法律 (2021-10-21)

research_industry_decree

研究产业振兴法施行令

总统令 (2024-06-01)

research_industry_rule

研究产业振兴法施行规则

科技信息通信部令 (2024-06-01)

lab_safety_act

实验室安全环境营造相关法律

法律 (2026-05-20)

lab_safety_decree

实验室安全环境营造相关法律施行令

总统令 (2026-05-20)

lab_safety_rule

实验室安全环境营造相关法律施行规则

科技信息通信部令 (2026-02-01)

Sector — 防卫事业厅国防 R&D 相关法规(8 个):

ID

名称

种类·施行日期

defense_tech_act

国防科学技术创新促进法

法律 (2024-07-10)

defense_tech_decree

国防科学技术创新促进法施行令

总统令 (2026-07-01)

defense_tech_rule

国防科学技术创新促进法施行规则

国防部令 (2021-04-01)

defense_rnd_guideline

国防技术研发业务处理指南

行政规则 (2026-02-10)

defense_tech_fee_notice

国防科学技术费算定ㆍ征收方法及征收程序等相关告示

行政规则 (2026-02-10)

defense_future_challenge_guideline

未来挑战国防技术研发业务处理指南

行政规则 (2026-02-10)

defense_facility_equipment

国防研发设施·装备管理等相关规定

行政规则 (2026-02-10)

defense_standard_agreement

武器体系研发标准协议书

行政规则 (2026-01-02)

Sector — 国土部 R&D 相关法规(5 个):

ID

名称

种类·施行日期

sector_kt_act

国土交通科学技术育成法

法律 (2026-02-01)

sector_kt_decree

国土交通科学技术育成法施行令

总统令 (2026-08-20)

sector_kt_rule

国土交通科学技术育成法施行规则

国土交通部令 (2018-06-08)

kt_rnd_operations

国土交通部所管研发项目运营规定

行政规则 (2026-07-08)

kt_autonomous_driving

(国土交通部) 自动驾驶技术开发创新项目运营管理规定

行政规则 (2026-07-08)

Sector — 产业部 R&D 相关法规(7 个):

ID

名称

种类·施行日期

industry_tech_act

产业技术革新促进法

法律 (2026-06-03)

industry_tech_decree

产业技术革新促进法施行令

总统令 (2026-06-03)

industry_tech_rule

产业技术革新促进法施行规则

产业通商资源部令 (2026-06-03)

industry_tech_operating

产业技术革新项目共同运营要领

行政规则 (2024-12-30)

industry_tech_security

产业技术革新项目保安管理要领

产业通商资源部告示 (2018-04-30)

industry_tech_evaluation

产业技术革新项目技术开发评价管理指南

产业通商资源部例规 (2024-12-30)

tech_fee_integrated

技术费征收及管理相关综合要领

产业通商资源部告示 (2025-04-07)

Sector — 中企部 R&D 相关法规(5 个):

ID

名称

种类·施行日期

sme_tech_act

中小企业技术革新促进法

法律 (2026-07-01)

sme_tech_decree

中小企业技术革新促进法施行令

总统令 (2026-07-01)

sme_tech_rule

中小企业技术革新促进法施行规则

中小风险企业部令 (2020-07-30)

sme_rnd_operating

中小企业技术开发支援项目运营要领

行政规则 (2026-01-21)

sme_tech_fee

中小企业技术开发支援项目技术费管理规定

中小风险企业部告示 (2026-04-02)

Sector — 福祉部 R&D 相关法规(4 个):

ID

名称

种类·施行日期

health_tech_act

保健医疗技术振兴法

法律 (2026-02-12)

health_tech_decree

保健医疗技术振兴法施行令

总统令 (2026-02-01)

health_tech_rule

保健医疗技术振兴法施行规则

保健福祉部令 (2024-07-17)

health_rnd_operating

保健医疗技术研发项目运营·管理规定

保健福祉部告示 (2023-12-26)

Sector — 疾病厅 R&D 相关法规(4 个):

ID

名称

种类·施行日期

kdca_rnd_management

疾病管理厅研发管理规定

行政规则 (2026-05-18)

kdca_agency_designation

疾病管理厅研发项目专业机构指定告示

行政规则 (2026-04-15)

kdca_facility_equipment

疾病管理厅国家研发设施·装备管理规定

行政规则 (2022-08-31)

kdca_relay_operating

(疾病管理厅) 国家研发成果泛部门接力项目共同运营指南

行政规则 (2021-02-02)

Sector — 教育部 R&D 相关法规(7 个):

ID

名称

种类·施行日期

sanhak_act

产业教育振兴及产学研合作促进相关法律

法律 (2025-06-21)

hakjin_act

学术振兴法

法律 (2021-06-23)

hakjin_decree

学术振兴法施行令

总统令 (2022-11-08)

sanhak_decree

产业教育振兴及产学研合作促进相关法律施行令

总统令 (2026-03-24)

hakjin_rule

学术振兴法施行规则

教育部令 (2020-10-13)

sanhak_rule

产业教育振兴及产学研合作促进相关法律施行规则

教育部令 (2026-03-27)

research_ethics_guideline

确保研究伦理的指南

行政规则 (2023-07-17)

Tier 1 — 成果评价相关法规(2 个):

ID

名称

种类·施行日期

performance_eval_act

国家研发项目等成果评价及成果管理相关法律

法律 (2023-10-31)

performance_eval_decree

国家研发项目等成果评价及成果管理相关法律施行令

总统令 (2025-04-01)

Tier 2 — 核心行政规则(5 个):

ID

名称

种类·施行日期

rnd_funding_standard

国家研发项目研发费使用标准

行政规则 (2026-05-06)

simultaneous_research_limit

国家研发项目同时执行研发课题数量限制标准

行政规则 (2021-01-01)

facility_equipment_standard

国家研发设施·装备管理等相关标准指南

行政规则 (2026-04-23)

research_note_guideline

国家研发项目研究笔记指南

行政规则 (2022-01-01)

innovation_challenge_criteria

创新挑战型研发项目群的指定及分类标准等相关告示

科技信息通信部告示 (2025-02-03)

Tier 2 — 共同行政规则追加(4 个):

ID

名称

种类·施行日期

rnd_info_processing

国家研发信息处理标准

行政规则 (2026-08-20)

rnd_security_measures

国家研发项目安保对策

行政规则 (2023-11-20)

large_rnd_plan_review

大型研发项目计划审查运营规定

科技信息通信部告示 (2026-03-26)

build_type_rnd_screening

构建型研发项目审查运用指南

科技信息通信部告示 (2026-05-11)

扩展方向: 支持规定将持续扩大。

  • 领域(广度): 收录泛部门共同·国土交通·产业·中小企业·保健医疗·疾病管理·教育(学术振兴·产学研合作) R&D 规定 → 将持续扩大至其他部门

  • 资料种类(深度): 以国家法令信息中心 OpenAPI 提供的法令·行政规则为中心 + 创新法手册解说(本卷 v0.27.0·别册 3 制裁处分指南 v0.32.0·别册 2 技术费制度手册 v0.33.0·别册 1 学生人工费综合管理制度手册 v0.35.0·课题评估标准指南 v0.38.0·KAIA 研究费不当执行案例集 v0.43.0 追加) → 将持续扩大补充资料

稳定使用

规定审查在本 MCP 工具被实际调用并引用依据条文时才是准确的。如果工具未被调用,AI 可能基于一般知识作答,此时数值·要件可能与实际规定不同,请参考以下内容。

  • claude.ai 网页中在同一对话中同时使用多个连接器(Google Drive·Gmail 等)时,对话过程中规定工具可能不会被调用。进行规定审查时,请暂时关闭不使用的连接器。

  • 如果回答在陈述规定内容时未提供条文引用(provision_id)或原文依据,则可能未调用工具(引用缺失并非确定,而是警告信号) → 请在新对话中重新提问。

  • 多次进行的重要规定审查,Claude Desktop·Claude Code(stdio 本地安装) 比网页连接器更稳定 — 工具按对话(会话)单位加载,中途缺失的可能性较低。

  • 支持范围 = 66 项规定(创新法 family·各部门 R&D·核心行政规则)。超出此范围的规定的回答是基于一般知识的指引,请同时确认国家法令信息中心等第一手来源。

功能

7 个 MCP 工具:

Tool

用途

health

确认服务状态·API 密钥设置情况

list_rule_sets

查询已登记的 66 项规定列表·hierarchy rank·文档 ID·主管部门

search_provision

在条文·附表正文中搜索关键词 → snippet + provision_id 候选 list。除入口错误外的正常响应附带回答底部标准指引完整版 standard_footer (v0.40.0) + 附带紧邻指示 standard_footer_note(列表型·包含 0 件回答的显示规则)(预算(16,000 字符)允许时附加·超出时仅保留 footer 的两级回退) (v0.41.0)

get_provision_detail

以 provision_id 逐字查询单一条文/附表正文(包含防止 LLM 任意编造副标题的 metadata)。按文档单位查询时同时提供附表标题列表 — 让 AI 不猜测附表而是查看标题后选择 (v0.2.1)。非错误响应附带回答底部标准指引完整版 standard_footer (v0.29.0)

suggest_review_sources

自然语言问题 → 关键词提取 → 待审查规定·条文候选 + 推荐审查顺序(法律 → 施行令 → 施行规则 → 行政规则)。未同时传递 keywords 时服务器的自动提取仅截取问题末尾的请求句('…规定候选与审查顺序'等),即使是相同词语,若用作条文术语则予以保留 (v0.42.0)。除入口错误外的正常响应附带 standard_footer (v0.40.0) + 附带紧邻指示 standard_footer_note(预算允许时·超出时仅保留 footer) (v0.41.0)

search_manual

「国家研发创新法手册」本卷 + 别册 3 「制裁处分指南」 + 别册 2 「技术费制度手册」 + 别册 1 「学生人工费综合管理制度手册」 + 「国家研发课题评估标准指南」(25.12) + 别册 4 「研究设施·设备费综合管理制度运营·管理手册」 + 「国家 R&D 研究费不当执行案例集」(KAIA·25.5) 综合搜索 — 按节单位匹配(source 区分资料) + 印刷页锚点摘录 + 完整引用句 citation (v0.39.0 以别册 4 完成系列·v0.43.0 追加案例集)

get_manual_section

查询手册·指南节正文(本卷 3-4 型·别册 3 b3-4-2 型·别册 2 b2-3-2 型·别册 1 b1-3-4 型·课题评估标准指南 eval-3-2 型·别册 4 b4-5[无章平面编排,单一层级]·不当执行案例集 case-2-2 型 id) — 大型节按页面边界分割为块。所有非错误响应附带规范性元数据(解说资料·法令优先)·完整引用句·底部标准指引块 (v0.28.0)。表格·公式结构未保留在提取文本中的节附带完整指引块 structure_notice (v0.34.0)

创新法手册解说 (v0.27.0)

「国家研发创新法手册」(本卷,26.7 版·以法令施行日 2026.6 月为准)正文解说部(5 章 40 节 + 参考资料 3 件·印刷 1332 页)与别册 3 「国家研发项目制裁处分指南」(26.7 发布套件·5 章 22 节 + 附录 1 件·印刷 189 页·v0.32.0 追加),别册 2 「国家研发项目技术费制度手册」(26.7 发布套件·3 章 14 节 + 附录 1 件·印刷 112 页·v0.33.0 追加),别册 1 「学生人工费综合管理制度手册」(26.7 发布套件·5 章 22 节 + FAQ + 参考资料 3 件·印刷 391 页·v0.35.0 追加),别册 4 「研究设施·设备费综合管理制度运营·管理手册」(26.7 发布套件·概述 + 正文 ⅠⅨ + 附件·印刷 350 页·v0.39.0 追加 — 至此本卷·别册 1~4 全部收录),「国家 R&D 研究费不当执行案例集」(国土交通科学技术振兴院(KAIA)·2025.05·按费用科目案例 105 件 + FAQ 18 问 + 检查·结算程序·v0.43.0 追加)可按节单位搜索·查询。

  • 别册 3 是制裁处分(参与限制·制裁附加金·追缴)的程序·标准·再审争议点解说。参与限制期限·制裁附加金比例等具体数值以施行令附表 6·附表 7 原文(get_provision_detail)为依据,引用时请交叉确认。别册 3 原文中未注明法令基准日,回答指引中会标注该事实。

  • 别册 2 是技术费制度(征收·政府缴纳技术费·减免·使用)与协议时技术贡献度计算·验证指南解说。技术费率·缴纳上限·缴纳期限等具体数值以施行令第 38 条~第 41 条原文(get_provision_detail)为依据,引用时请交叉确认。别册 2 原文中同样未注明法令基准日,正文部分术语(例: 技术费等缴纳义务机关)是 2026-07-28 施行施行令修订前的术语。

  • 别册 1 是学生人工费综合管理制度(使用用途·计列标准·综合管理账户·支付·余额与利息处理·转移·返还·综合管理机构指定与指定取消)解说与 FAQ·指定现状·标准运营指南·检查资料集。计列标准·支付额·转账期限等具体数值以「国家研发项目研究开发费使用标准」原文(get_provision_detail·rnd_funding_standard)为依据,引用时请交叉确认。别册 1 原文中同样未注明法令基准日,原文引用的告示编号(第 2026-5 号)是发布时点的标注,可能与现行修订本编号不同,学生人工费利息处理叙述以旧版告示第 75 条结构为准(回答指引中会标注该事实)。

  • 别册 4 是研究设施·设备费综合管理制度(施行机构指定·综合管理账户开设与运营·计列·支付·积存·使用·管理·监督·指定取消)解说。因无章平面编排,节 id 为单一层级(b4-0 概述·b4-1b4-9 正文 ⅠⅨ·b4-ref-1 附件)。积存·使用要件与指定·取消标准等具体数值以「国家研发项目研究开发费使用标准」第 7 章(第 100 条~第 111 条)原文(get_provision_detail·rnd_funding_standard)为依据,引用时请交叉确认。附件的规定摘录是按原文附则标注基准告示第 2023-49 号(2023.12.28.)的快照,已确认与现行告示存在措辞不同的部分(回答指引中会标注该事实)。

  • 「国家 R&D 研究费不当执行案例集」是国土交通科学技术振兴院(KAIA)发布的教育·参考用案例集(按费用科目结算不认可案例 105 件·FAQ 18 问·研究费使用前注意事项·定期·年度检查/结算程序)。节 id 为 case-1-1(Ⅰ 开始之前)·case-2-1~case-2-10(Ⅱ 按费用科目案例)·case-3-1(Ⅲ FAQ)·case-4-1(Ⅳ 检查·结算程序)。案例并非对个别案件的结算判定·制裁处分决定,结论可能因机构类型·协议·凭证而不同,具体金额·比例·条文请以「国家研发项目研究开发费使用标准」现行原文交叉确认。Ⅳ章的检查·结算程序(Ez-baro·委托结算机构·日程)以 KAIA 国土交通 R&D 流程为准,其他部门课题需确认相应专业机构(回答指引中会标注该事实)。

  • 手册·案例集是解说·参考资料 — 并非法令·行政规则,内容不一致时以法令·行政规则原文为准。义务·期限·金额等规范性依据请始终通过法令工具(search_provision·get_provision_detail)确认。

  • 所有手册回答均附带包含版本号·基准日·法令优先原则的规范性元数据(manual_meta)与来源标注(notice)。

  • 收录范围: 本卷正文解说部 + 别册 3 「制裁处分指南」全文(印刷 189 页) + 别册 2 「技术费制度手册」全文(印刷 112 页) + 别册 1 「学生人工费综合管理制度手册」正文(印刷 391 页 — 不含章标题扉页·空白页) + 别册 4 「研究设施·设备费综合管理制度运营·管理手册」正文(印刷 350 页 — 不含扉页·空白页),即 **本卷·别册 14 全部收录**,另加「国家 R&D 研究费不当执行案例集」正文(印刷 695 页 — 不含封面·目录·扉页·空白页·v0.43.0)。附录相关格式(自 26.7 版起另行以单独 PDF 发布)未收录。

  • 手册由 KISTEP 随时发布修订版(2026 年共两次,4 月·7 月) — 在反映修订版之前,手册基准日之后的法律修订可能未反映在解说中。

1 个 MCP prompt:

Prompt

用途

review_regulation

多层次规定审查 — 对特定案例按层级顺序适用 66 项规定,并附依据条款引用回答规定审查结果。需在 prompt 中包含 'korean-rnd-regs-mcp'、'规定审查' keyword


Troubleshooting

Q0. 服务器更新后看不到新工具(search_manual 等)

服务器新增工具的更新(输入 schema 新设)后,客户端可能缓存了之前的工具列表。

  1. claude.ai 网页连接器: 点击连接器详情画面的 ⋮ 菜单 → "Refresh tools list" 即可在不断开连接的情况下仅刷新工具列表(推荐)。如果仍然看不到,请将连接器停用 → 重新启用(重新连接)。无论哪种方式,刷新后都需在新对话中使用,进行中的对话可能保留之前的工具列表。

  2. Claude Desktop / Claude Code(stdio): 重启应用或执行 /reload-plugins 后开始新对话。

  3. 重新连接后仍看不到,请通过 health 确认服务器 version 是否为最新。

Q1. AI 回答"找不到相关条文"

  1. 请 AI 确认工具响应的 errors 字段 — API 认证失败等会通过 errors 传递

  2. 通过 health 工具确认 api_key_configured: true

  3. 国家法令信息中心 OpenAPI 我的页面确认 LAW_API_KEY 是否正确

  4. 去除密钥字符串前后的空格

Q2. AI 编造了条文正文中不存在的副标题或摘要

  • 在 prompt 中添加"请勿编辑,原样引用"或"verbatim"字样

Q3. 输出的是过去曾使用的条文,而非现行施行的条文。

  • 如果未调用本工具(MCP)而进行作业,可能会出现与问题相同的结果。

    • 请在 prompt 中注明本 MCP 的名称后发送。

Q4. "auth_failed" 错误

  • LAW_API_KEY 为空或错误。请到 open.law.go.kr 我的页面 → 重新签发 API 密钥

  • 如果通过远程(网页连接器)使用,请确认连接器 URL 的 ?oc= 值是否与本人的 API 密钥一致。

Q5. "rate_limited" 错误

  • 已达到每日调用限制。等待 24 小时后重试。缓存(24h)可减少相同 query 的重复调用

Q6. (ChatGPT) 工具批准窗口显示警告,或查询被归类为"写入"

  • ChatGPT 在调用工具前会弹出批准窗口,连接本服务器时可能同时显示对工具说明的警告(InstructionAttempt 等)。本服务器的工具说明中包含要求不加摘要·不变形地逐字引用法令条文原文的指令,ChatGPT 的自动分类器似乎将此类输出相关指令标记为危险信号(警告判定标准未由 OpenAI 公开,无法确认确切原因)。请在连接前确认服务器地址与运营主体后自行判断是否批准。

  • 本服务器的 7 种工具均为查询专用,自 v0.36.0 起已赋予只读标识(readOnlyHint)。如果之前已连接,在工具列表刷新前可能显示为"写入",请在插件(连接器)管理画面的"刷新"中更新工具列表(无需重新登记·重新输入密钥)。

Q7. (ChatGPT) 回答底部的标准指引不显示

  • 观察到 ChatGPT 中收到搜索·候选列表的回答底部不显示标准指引(法令原文确认·手册来源指引)的情况。同一连接器·同一服务器上使用更高阶模型提出相同问题时可正常显示,据此判断是服务器发送的响应后部指引字段在回答组装过程中被遗漏的模型差异(发生条件与频率无法确认)。服务器正常一并发送该指引,对服务器返回的条文字段无影响(但回答整体的准确性请另行确认)。如需确认原文,请在国家法令信息中心对照。


开发者用

本地开发环境

git clone https://github.com/smilemin07/korean-rnd-regs-mcp.git
cd korean-rnd-regs-mcp
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate
pip install -e ".[dev]"

运行测试

pytest
# 643 passed (mock 기반, 네트워크 미사용)

构建

python -m build
twine check dist/*

安全

LAW_API_KEY 是从国家法令信息中心 OpenAPI 免费签发的公开法令数据查询用认证值。与金融 API 密钥等性质不同,但请妥善管理,防止他人未经授权使用。

  • 泄露时,他人可能以同一密钥重复请求,影响使用

服务器的保护范围

  • 服务器内部自动隐藏工具响应、错误消息等中的 API 密钥

  • 与法令信息 API 的通信使用 HTTPS 加密

用户注意事项

  • 请勿在聊天、截图、SNS 等中暴露 API 密钥

  • 使用远程连接(HTTP 模式)时 URL 中包含 API 密钥 — 可能留在浏览器历史、终端历史中,请勿在公用 PC 上使用。

  • 如果直接以 --http 模式托管服务器,请将 FASTMCP_HOST=127.0.0.1 绑定限制在 loopback(未设置·空值·空白时出于兼容性会绑定到所有接口 0.0.0.0,同一 LAN 内可不经隧道·代理直接访问端口)。但该设置仅减少内核网络接口暴露 — 无法阻止同一主机上代替以 loopback 连接的进程(例: Synology Tailscale 的 userspace networking 将 tailnet 请求代理到 127.0.0.1)的到达,此类路径请通过 Tailscale ACL 等相应工具的策略另行管控。

密钥泄露时的应对

密钥泄露时可在 open.law.go.kr 删除现有密钥并重新签发。

详细安全政策·漏洞报告: SECURITY.md


Disclaimer

本工具为支持规定审查业务而开发。判断结果的责任由用户本人承担。


License

Apache License 2.0

Contributing

欢迎提交 issue·PR: https://github.com/smilemin07/korean-rnd-regs-mcp/issues

Changelog

2026. 8. 11.: v0.48.0

  • 改进规定搜索·查询响应速度(法令信息 API 连接复用 — 稳定性更新,无功能·数据变更)

2026. 8. 10.: v0.47.0

  • 新增科技部规定 2 件(大型研发项目计划审查运营规定,构建型研发项目审查运用指南 / 支持规定 64 → 66 件)

2026. 7. 25.-8. 8.: v0.27.0-v0.46.0

  • 支持国家研发创新法手册('26.7)

    • 本卷,别册 1(学生人工费综合管理制度手册),别册 2(国家研发项目技术费制度手册),别册 3(国家研发项目制裁处分指南),别册 4(研究设施·设备费综合管理制度运营·管理手册)

  • 支持国家 R&D 研究费不当执行案例集(KAIA 发布,'25.5)

  • 支持国家研发课题评估标准指南('25.12)

  • 改进施行前的规定被当作现行规定提供的问题等

2026. 7. 24.-25.: v0.26.0-v0.26.1

  • 新增国土部自动驾驶 R&D 行政规则 1 件((国土交通部)自动驾驶技术开发创新项目运营管理规定 / 支持规定 63 → 64 件)等

2026. 7. 24.: v0.25.0

  • 防卫事业厅国防R&D行政规则新增3项(未来挑战国防技术研发业务处理指南·国防研发设施及装备的管理等相关规定·武器体系研发标准协议书 / 支持规定60 → 63项)等

2026. 7. 23.: v0.24.0

  • 防卫事业厅国防R&D行政规则新增2项(国防技术研发业务处理指南·国防科学技术费告示 / 支持规定58 → 60项)

    • 为管理响应速度,上调内部缓存上限(64→96)等

2026. 7. 23.: v0.23.0

  • 新增支持防卫事业厅国防R&D规定3项(国防科学技术创新促进法·施行令·施行规则 / 支持规定55 → 58项)

    • 增加让AI认知到国防R&D适用的是国防科学技术创新促进法体系而非国家研究开发创新法的机制等

2026. 7. 22.: v0.22.0

  • 新增支持科技部R&D规定3项(实验室安全环境营造相关法律·施行令·施行规则 / 支持规定52 → 55项)

2026. 7. 9.: v0.17.0

  • 改进为可向AI提供法令的最新修订内容(变更了什么)(新制定的法令标注为"制定"后提供)等

2026. 7. 5.-8.: v0.13.0-v0.16.0

  • 新增支持科技部R&D规定1项(创新挑战型研究开发事业群的指定及分类标准等相关告示 / 支持规定51 → 52项)

  • 改进为可向AI提供条款的最近修订历史(公布日期等)

  • 改进为可输出分支条款("第2条之2"等)等

2026. 6. 29.-7. 1.: v0.10.0-v0.12.0

  • 新增支持科技部R&D规定6项、产业部R&D规定2项(企业附属研究所等的研究开发支持相关法律family等 / 支持规定43 → 51项)

  • 改进为可准确输出法令条款中"号"之下"目"所对应的规定

2026. 6. 26.: v0.9.1

  • 搜索速度及稳定性改进

    • 防止同时用户数增加时可能发生的卡顿等

2026. 6. 24.: v0.9.0

  • 新增支持教育部R&D规定4项(产学研究合作family 3项 + 确保研究伦理指南 / 支持规定39 → 43项)

2026. 6. 24.: v0.8.0

  • 新增支持教育部R&D规定3项(支持规定36 → 39项)

2026. 6. 21.-22.: v0.5.0-v0.7.0

  • 向AI提供行政规则的发布编号及种类(例如:例规第179号)

  • 强化条款搜索能力等

    • 改进AI查找特定条款(例如:XX规定第2条)时,因缺乏该条款标识符信息而进行网络搜索后以旧条款作答的现象

      • 标识符示例:产业技术创新事业共同运营要领第2条 → admrul:2100000251982:JO0002

2026. 6. 20.: v0.4.0-v0.4.1

  • 新增支持疾病厅R&D规定4项(支持规定32 → 36项)

  • 上调搜索结果缓存容量(为应对规定扩充)等

2026. 6. 20.: v0.3.0

  • 新增支持福利部保健医疗技术R&D规定4项(支持规定28 → 32项)

  • 对未支持规定作答时增加幻觉(hallucination)减少机制:以一般知识说明本服务器范围之外的规定时,增加引导确认第一手来源(国家法令信息中心)的机制

2026. 6. 17.-20.: v0.2.8-12

  • 搜索结果相关度排序:收到涉及多个领域的问题时,因响应大小限制导致后部结果被截断时,改进为不再截断与问题最相关的规定

  • 运行安全性改进、安全强化工作等

2026. 6. 14.: v0.2.7

  • 运行稳定性强化:查询多个规定时,改进因部分响应较慢的请求导致整体工作延迟的问题

2026. 6. 13.: v0.2.6

  • 支持规定重组(25 → 28项):删除辅助规定6项,新增泛部门&科技部&产业部&中小风险企业部R&D规定9项

    • 删除辅助规定(6项):反腐败·禁止请托·公益举报人保护法律·施行令

      • 因与本MCP的主要服务(研究开发规定审查)关联性较低,从支持规定中排除

    • 新增泛部门&科技部&产业部&中小风险企业部R&D规定(9项):成果评价法·施行令,国家研究开发信息处理标准,国家研究开发事业保安对策,科技部所管科学技术领域处理规定,信息通信·广播研究开发管理规定,信息通信·广播研究伦理规定,技术费统一要领(产业部)·中小企业技术开发技术费管理规定(中小风险企业部)

  • 在规定列表(list_rule_sets)中增加主管部门信息,将附表之外附属文件(含附件·附录)无法查询的说明通用化等

2026. 6. 13.: v0.2.5

  • 扩大支持规定(17 → 25项):新增产业部·中小风险企业部R&D核心规定8项

    • 产业技术创新促进法·施行令·施行规则 + 产业技术创新事业共同运营要领

    • 中小企业技术创新促进法·施行令·施行规则 + 中小企业技术开发支持事业运营要领

2026. 6. 12.: v0.2.4

  • 将国家研究开发创新法·施行令·施行规则的2026. 6. 11. 施行修订生效反映到规定列表信息中

  • 在大容量附表中以多个搜索词查找时,修正高频词独占摘录位置导致目标机构行被遗漏的问题

2026. 6. 12.: v0.2.3

  • 在大容量附表(例如:研究开发费使用标准附表6间接费告示比率表)中搜索词命中的行有多处时,改进为同时摘录显示这些行(最多6处)

    • (原有)仅摘录第一个命中的行周边,导致目标机构·数值的行被遗漏的情况发生

2026. 6. 11.: v0.2.2

  • 强化引导文案,避免AI在查找附表·附页时陷入死胡同等

    • 例如:附页·格式不支持说明,附表查询失败时的重新搜索路径说明

2026. 6. 10.: v0.2.1

  • 确认条款详细内容需要参考附表时 → 增加引导AI查询附表的机制

  • 改进为可查询分支附表(例如:'附表1之2'等)等

2026. 6. 9.: v0.2.0

  • 改进为可加载国家研究开发创新法施行令的附表

2026. 6. 8.: v0.1.10

  • 在程序型回答中增加视觉流程

    • (原有)即使是以程序·顺序为核心的问题,回答也仅以文字呈现,难以一目了然地把握步骤·分支

    • (变更)审查结果包含分步程序·条件分支时,强化审查提示词,在回答中同时以步骤流程(文本图示)形式呈现并标注各步骤依据条款

2026. 6. 7.: v0.1.9

  • 强化条款搜索能力

    • (原有)未能从AI接收用于搜索相关条款的Keyword,导致无法Fetch适合规定审查的条款的情况发生

    • (变更)未能从AI接收Keyword时 → 插入引导AI向MCP服务器端发送Keyword的机制

2026. 6. 7.: v0.1.8

  • 强化条款搜索能力

    • (原有)相关条款较多时仅返回前部一部分,导致AI无法参考其他相关条款(例如:'事前批准程序')的信息

    • (变更)将前部列表中被挤出的条款也以'标题 + 标识符'形式一并提供 → 修改为AI可自行查找所需条款、确认正文后进行规定审查

2026. 6. 6.: v0.1.7

  • 强化条款搜索能力

    • (原有)偶然包含大量一般性词语(例如:政府支持研究开发费)的条款占据前列,导致规定审查所需的条款(例如:'协议变更'、'事前批准对象')被挤出前部列表

    • (变更)优先搜索条款'标题'与问题关键词直接匹配的条款

2026. 6. 5.: v0.1.6

  • 强化条款搜索能力

    • (示例1)提示词中使用'征出金'表述

      • (原有)条款中不存在'征出金'一词时 → 即使是规定审查所需的条款也无法加载

      • (变更)扩展为'政府支持研究开发费'、'出资额'等含义相近的词语进行条款搜索 → 规定审查时参考相关条款

    • (示例2)提示词中使用'协议变更'表述(名词短语)时

      • (原有)条款标题为'协议的变更'时 → 即使是规定审查所需的条款也无法加载

      • (变更)条款标题为'协议的变更'时也作为相关条款参考,进行规定审查

2026. 6. 4.: v0.1.5

  • 修改向OpenAPI侧请求的'主要keywords'提取流程

  • 强化LLM响应稳定性 — 审查候选较多时,按层级·重要度优先返回,遗漏部分通过整体文档列表·追加搜索引导(防止大容量响应截断)。

    • 设置发送至LLM的相关条款上限(修正MCP向LLM发送过量信息导致的错误)

2026. 5. 31.: v0.1.4

  • 修改为始终参考当前施行的规定

  • 强化规定审查提示词等

    • 增加条款要件解释·事实关系1:1对照流程等

2026. 5. 25.: MCP公开

完整变更历史请参考 CHANGELOG.md

Available Tools

2 tools
healthA

서비스 상태 확인 — status, service name, version, API 키 설정 여부.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. Only discloses what fields are returned, not behavioral aspects like side effects, rate limits, or authentication requirements. The tool is likely read-only, but this is not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence clearly front-loads the purpose and lists key outputs. No wasted words.

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

Completeness4/5

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

Tool has no parameters and an output schema exists. Description adequately covers what it does and returns. Could mention if authentication is required, but for a health check, this is acceptable.

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?

No parameters; schema coverage is 100%. Baseline 4 applies as description adds no param info, but none is needed.

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?

Description clearly states the verb 'check' and resource 'service status'. Lists specific fields returned: status, service name, version, API key configuration. Distinguishes from sibling 'search_provision' by being a health check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No context on prerequisites or scenarios. For a health check, usage is somewhat self-evident, but explicit guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_provisionA

사용 시점: 국가연구개발·R&D 연구행정 규정의 조문·용어·현행 여부를 묻는 질문에는 일반 학습지식 답변 전에 호출하십시오. 본 서버 범위 밖 일반 대화·번역·문장 다듬기에는 호출하지 마십시오.

규정 조문·별표 본문에서 query 키워드를 찾아 후보 list 반환.

manifest의 live_api 문서들을 대상으로:

  • law(혁신법·시행령·시행규칙): 조문(조문내용) + 별표(별표내용) 검색 (v0.2: 시행령 별표 지원)

  • admrul(연구개발비 사용 기준 등): 조문 + 별표(별표내용) 검색

    • 각 항목의 unit_types (article/annex/both)에 따라 검색 범위 결정

    • 별표는 별표구분=='별표'만 노출 — 별지·서식 제외 (v0.2.1, BP 번호 충돌 오도달 방지)

응답 최상위에 짧은 disclaimer 1개만 두고, 각 결과에는 manifest 특유의 warnings만 첨부. snippet은 _SNIPPET_MAX (2000자)로 제한, 전체 응답은 16k char 예산 내(초과 시 뒤쪽 결과 절단·truncated=true — 광역 질의는 키워드를 좁혀 재검색할 것) — MCP output size limit 회피.

v0.16.0: law 조문 매치에 최신 개정 이력 힌트가 있으면 latest_history(예 "개정 2025.12.30(공포)")를 additive 노출 — '최근 개정 조문' 질의에서 검색 결과만으로 개정 조문을 인지 가능(마커 부재 매치·평면 admrul·별표는 생략). 날짜는 공포일(값에 (공포) 표기·시행일 아님)이고, 검색 매치는 키워드에 걸린 조문에 한정되므로 특정 법령의 개정 조문 전수 확인은 문서레벨 get_provision_detail(unit 없이)의 articles 목록으로.

매칭 (v0.1.6): query를 공백으로 토큰 분해하여 모든 토큰(2자 이상)이 한 조문/별표의 제목 또는 본문에 존재하면 매칭(토큰 AND). 단일 토큰 query는 종전과 동일한 부분문자열 매칭. 원문이 "협약의 변경/협약을 변경"으로 써서 "협약 변경"이 안 잡히던 띄어쓰기 불일치를 해소.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

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

No annotations provided, but description fully covers search algorithm (token AND, substring matching, spacing handling), response structure (disclaimer, warnings, snippet limits, truncation), and version-specific features (latest_history). Very transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is quite long and detailed, but well-organized with clear sections and bullet points. It includes necessary technical information, though could be more concise for agent consumption.

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?

Given the complexity of the tool (multiple document types, matching logic, response limits, version history), the description is comprehensive. It covers search behavior, response format, and even references related tool 'get_provision_detail' for completeness.

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?

Only one parameter 'query' with no schema description. The description compensates by explaining how the query is used: tokenized, matched against regulation text, and with specific matching rules. Adds significant meaning beyond the schema.

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 description clearly states the tool's purpose: searching Korea's national R&D regulations for clauses, terms, and current status. It explicitly distinguishes from general knowledge tools and provides a explicit call pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use and when-not-to-use guidance (e.g., 'call before general knowledge answers' and 'do not call for general conversation'). Does not explicitly name alternative tools but strongly implies context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A3.8/5.0
Disambiguation5/5

The two tools serve completely different purposes: health is a status check, search_provision is a search tool. There is no overlap or ambiguity.

Naming Consistency4/5

'health' is a noun while 'search_provision' follows a verb_noun pattern. Minor inconsistency, but the small set makes it acceptable.

Tool Count3/5

Only two tools for a domain that likely requires more operations (e.g., fetching full provisions). The count feels slightly thin but not extreme.

Completeness2/5

The search tool allows querying, but there is no tool to retrieve full details of a provision (despite mentioning get_provision_detail in the description). This gap will hinder workflows.

Maintenance

ActivityActive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    B
    maintenance
    Enables AI systems to search, retrieve, and analyze Korean legal information from the National Law Information API (law.go.kr), including laws, administrative rules, English translations, and law-ordinance linkages.
    26
    2
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI to search and retrieve South Korean legal information from the National Law Information Center. It allows users to look up specific laws, articles, and detailed legal provisions using natural language queries.
    128
  • A
    license
    A
    quality
    D
    maintenance
    Enables users to search and retrieve South Korean statutes, precedents, and administrative rules via the National Law Information Center API. It supports deep legal chain analysis, legislative history tracking, and legal terminology lookups through natural language.
    10
    5
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables exploration of Korean National Assembly data by connecting bills, committee reviews, and official records. Allows users to ask natural language questions and receive structured answers with citations to original documents.
    25
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smilemin07/korean-rnd-regs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server