This server is a read-only MCP tool for searching and retrieving the official 2022 revised Korean special education curriculum (middle/high school), with source tracking and no login required.
get_coverage_report: Check which statutory texts and supplementary materials are included or missing in the local dataset.
list_official_sources: List official notices, separate volumes, URLs, extraction status, and chunk counts.
search_curriculum: Search curriculum content by keyword, school level, curriculum type, subject, material kind, or specific source, returning official source info, page numbers, and URLs.
get_curriculum_chunk: Retrieve a longer original-text chunk using a sourceId and chunkId for deeper context.
find_achievement_standard: Look up achievement standard codes (e.g., [12국어01-02] or 9국어01-01) and return their source and context.
All tools are read-only, local, and do not require authentication or API keys.
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., "@korean-special-education-curriculum-mcp 고등학교 기본 교육과정 국어 성취기준을 쪽수와 함께 찾아줘."
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.
A read-only MCP server for exploring, with sources, the basic, common, and elective-centered curricula of middle and high school in the Republic of Korea's 2022 revised special education curriculum.
The current version is v0.1.0-candidate. Rather than distributing official source texts in the repository, it reproduces a local search corpus linked to notices, separate volumes, file hashes, and page locations.
Prerequisites are Git and Node.js 20 or higher. After cloning the repository, run the following command.
git clone <이 저장소의 GitHub URL>
cd korean-special-education-curriculum-mcp
npm install
npm run sources:prepare
npm run check
npm run test:mcpsources:prepare automatically downloads and structures materials obtainable from public URLs. If optional supplementary materials requiring a login to the publishing agency are absent, it only prints a warning and continues preparing the remaining materials. Use get_coverage_report to check the actual scope available to the server and any missing materials.
OS-specific connection methods and examples for first-time users are documented in docs/USER_GUIDE.md.
Related MCP server: ClassCraftMCP
Middle school and high school
Basic curriculum
Common curriculum
Elective-centered curriculum
Ministry of Education Notice No. 2022-34 and subsequent revision notices
The current reference date is 2026-08-19, and National Education Commission Notice No. 2026-2 serves as the special education baseline. Notice No. 2024-3 is also collected to verify the application relationship of general subjects in the common and elective-centered curricula.
81 official sources prepared: 35 statutory curricula, 1 commentary, 17 assessment materials, 28 research and review materials
29 items in the current statutory scope: Special Education Separate Volumes 1, 2, and 3, and 26 general curriculum separate volumes applied mutatis mutandis to middle and high schools
File signature verification, SHA-256, final URL, and collection timestamp recording
HWP/HWPX/PDF → Markdown and structural chunk conversion using kordoc
Local search corpus of 26,354 pages and 112,889 chunks
Middle school/high school and basic/common/elective-centered filters
materialKind filter separating statutory source texts, commentaries, achievement/assessment, and research materials
Read-only STDIO MCP including source URLs, notice numbers, page counts, and table-of-contents paths
npm install
npm run sources:prepare
npm run check
npm run test:mcp
npm run serveOfficial document downloads and extraction results are subject to .gitignore. Reproduction information is recorded in sources/official/source-receipts.json.
Statutory curricula and public supplementary materials do not need to be downloaded separately. npm run sources:prepare downloads, verifies, and converts them from official URLs. Eduable member-access materials are optional; the catalog records the original file names and ZIP internal paths in manualAcquisition. If you obtain the originals yourself and place them under the designated English file names in sources/official/files/, they are included in the full corpus. When missing, the collector prints the required files and target names, then continues processing the remaining materials that can be collected automatically.
Whether all materials are fully prepared locally can be strictly verified with the following command.
npm run check:fulllist_official_sources: current baseline, sources, preparation status, and chunk counts
get_coverage_report: preparation and missing status of current statutory source texts and supplementary materials
search_curriculum: filtered search by keyword, school level, curriculum type, subject, and material kind
get_curriculum_chunk: retrieve the source-text context and location of search results
find_achievement_standard: search achievement standard codes
It runs as a local STDIO server. After building, use the following command in the project-scoped .codex/config.toml or Codex MCP settings.
node <absolute-project-path>/dist/src/server.jsAn example Codex project configuration is as follows.
[mcp_servers.korean-special-education-curriculum]
command = "node"
args = ["<absolute-project-path>/dist/src/server.js"]Run npm run sources:prepare and npm run build once before connecting the server.
After connecting, it is recommended to first confirm the scope with a request such as the following.
특수교육 MCP의 get_coverage_report로 현재 수록 범위를 확인해줘.Example follow-up questions are as follows.
고등학교 기본 교육과정 국어 성취기준을 고시 원문, 쪽수, URL과 함께 찾아줘.
[12국어01-02]의 원문과 성취기준 해설을 구분해서 보여줘.
진로와 직업 과목에서 안전과 관련된 내용을 고시 원문만 대상으로 검색해줘.All general curriculum separate volumes applied mutatis mutandis by Separate Volume 2 of National Education Commission Notice No. 2026-2 that fall within the middle and high school scope are included: Separate Volumes 3, 4, 7, 12, 14, 18, 19, 22, 23~39, and 41. The 29 current statutory source texts undergo an independent completeness check in get_coverage_report. The 6 previous notices are preserved for change history and source verification but are excluded from the default search.
Commentaries, assessment materials, and research materials are not documents with the same legal effect as the statutory curriculum, so they are marked as a separate material kind. The index covers 26 middle and high school scope items from the National Institute of Special Education's 2022 special education curriculum draft research, the 2025 national curriculum special education survey and review report, assessment guides and basic curriculum assessment materials, 2026 high school achievement level materials, and physiotherapy and vocational life achievement levels and minimum achievement level guarantee guidance materials. Eduable member-access materials are processed locally only from originals obtained directly by users and are not included in Git. Known gaps in the defined special education-only supplementary material scope can be confirmed as 0 items in get_coverage_report.
This project is not an official product of the Ministry of Education, the National Education Commission, or NCIC. Official documents follow the terms of use of their respective original sources, and this repository's MIT license does not apply to official documents. See PROVENANCE.md, ACKNOWLEDGEMENTS.md, and THIRD_PARTY_NOTICES.md for details.
See CONTRIBUTING.md for reporting errors and contributing improvements, and SECURITY.md for reporting security issues.
예: 9국어01-01 또는 [12진로01-01] 같은 성취기준 코드를 찾아 출처와 문맥을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| limit | No | ||
| curriculumType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds that it returns 'source and context,' but doesn't disclose any other behaviors like pagination or error cases, so it's adequate but not rich.
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?
One concise sentence with an example, no fluff. It's efficient and front-loaded, earning every character it uses.
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 three parameters and no output schema, the description provides the core purpose and output type, but lacks parameter semantics and usage timing. It's sufficient for a simple lookup but leaves gaps for the optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter explanations beyond examples of code formats. The limit and curriculumType parameters are entirely unexplained, leaving the agent to guess their semantics.
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 finds achievement standard codes and returns their source and context, with concrete examples of code formats. This is specific and distinct from sibling tools by focusing on code lookup rather than broader curriculum 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?
The description implies the tool is for finding achievement standard codes, but it doesn't explicitly state when to prefer this over search_curriculum or other siblings. No exclusions or alternative guidance is provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
중·고등학교 특수교육 고시 원문과 준용 일반교육과정 별책의 수록 완전성, 아직 별도 수집 중인 보조자료 범위를 보고합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds context about 'still being collected separately,' indicating the report may reflect incomplete data. However, it does not clarify the report's format, limitations, or any side effects beyond what annotations imply, so it adds modest value.
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 sentence, but it packs substantial detail about the report's content. It is not overly verbose, though splitting into two sentences could improve readability. The core information is front-loaded before the verb, which is acceptable in Korean. Overall, it earns its length.
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 (no parameters, no output schema), the description sufficiently conveys what the report covers. It mentions completeness of certain documents and scope of auxiliary materials, which is the core purpose. Without an output schema, some might expect a clearer description of the return format, but for a simple report tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema to elaborate. The description provides no parameter-related information, which is appropriate. Baseline for 0 parameters is 4, and the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports on the completeness of curriculum inclusion and scope of auxiliary materials, which is a clear purpose (a coverage report). It distinguishes from sibling tools that focus on listing, searching, or chunk retrieval. However, it lacks specificity about exactly which documents are covered and the nature of 'auxiliary materials,' so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking coverage/completeness, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. Given the existence of sibling tools (search, list), some inference is possible, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
검색 결과의 sourceId와 chunkId로 해당 원문 청크와 정확한 출처 위치를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| chunkId | Yes | ||
| maxChars | No | ||
| sourceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by stating that it returns the '원문 청크와 정확한 출처 위치' (original text chunk and exact source location), which is behavioral information not present in the annotations. No contradiction 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?
A single, front-loaded sentence that clearly communicates the tool's purpose and inputs without wasted words. It is concise and efficient, with no redundant information.
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 retrieval tool with 3 parameters and no output schema, the description adequately states what is returned (chunk and source location) but lacks details about maxChars behavior, error conditions, or response format. Given the absence of an output schema, more detail about the return value would improve completeness, but the description is minimally acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions sourceId and chunkId as inputs but does not explain their meanings beyond the names, and completely omits maxChars, which controls chunk length. The agent cannot infer syntax or purpose of maxChars from the description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('조회합니다' - retrieves) and resource ('educational curriculum chunk'), and explicitly mentions the inputs (sourceId and chunkId) and outputs (original text chunk and exact source location). It distinguishes itself from siblings like search_curriculum by targeting a specific chunk from search results.
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 the tool is for use after a search ('검색 결과의'), providing clear context that it retrieves a chunk given IDs. It does not explicitly name alternatives or exclusions, but the purpose is evident from the phrasing, making it clear when to use it versus a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
현행 기준일, 고시·별책, 원문 URL, 추출 여부와 청크 수를 나열합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context about the output fields, but does not disclose additional behavioral traits such as whether it returns all sources, pagination, or ordering. With annotations in place, the description provides minimal extra value 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?
The description is a single, compact sentence that front-loads the action and lists the key outputs. Every word is meaningful, with no filler or redundancy. It is appropriately sized for the tool's simplicity.
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 lack of parameters, output schema, and straightforward nature, the description is mostly complete. It identifies all the data points returned, but could be slightly more explicit about the scope (e.g., 'all official sources' or 'current official sources') and whether any filtering applies. However, for a simple listing tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information to add, but the description clarifies what the tool returns, which indirectly helps users understand the tool's scope. Since there are no parameters, the description fully covers the semantics.
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 what the tool lists: current base date, notifications/supplements, original URL, extraction status, and chunk count. The verb '나열합니다' (list) is specific and the resource is explicit, distinguishing it from sibling tools like search_curriculum or get_curriculum_chunk, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios where it should be preferred, nor any exclusions or prerequisites. The description only states what it does, leaving usage decisions to inference from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
중·고등학교 특수교육 교육과정 고시 원문 또는 별도 해설서 청크를 검색합니다. 결과마다 자료 유형, 고시·자료명, 쪽수, 목차 경로와 공식 출처 URL을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | 검색어 또는 성취기준 코드 | |
| subject | No | 교과명 필터(예: 국어, 진로와 직업) | |
| sourceIds | No | 특정 공식 문서만 검색 | |
| schoolLevel | No | 중학교 또는 고등학교 필터 | |
| materialKind | No | statutory=고시 원문, commentary=해설서 | statutory |
| curriculumType | No | ||
| includeSuperseded | No | 현행 검색에서 제외된 구 총론 포함 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by specifying the document types searched (고시 원문 vs 해설서) and the exact return fields (자료 유형, 고시·자료명, 쪽수, 목차 경로, 공식 출처 URL), providing useful behavioral context without contradicting 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 consists of two efficient sentences: the first defines the action and scope, the second enumerates the return fields. There is no repetition, fluff, or irrelevant detail, making it easy to parse at a glance.
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 an 8-parameter tool with no output schema, the description adequately communicates the search domain and result format. It does not describe search semantics like fuzzy matching or pagination, but the annotations and schema defaults (e.g., materialKind default, limit bounds) fill in most gaps, making it complete enough for agent selection.
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 75%, meaning most parameters are already explained. The description maps major concepts (중·고등학교, 고시 원문/해설서) to schoolLevel and materialKind parameters, but leaves limit and curriculumType untouched. Since the schema carries most of the semantic weight, the description adds only modest value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('검색합니다' – searches) and resource ('중·고등학교 특수교육 교육과정 고시 원문 또는 별도 해설서 청크'), with clear scope. It distinguishes itself from siblings like get_curriculum_chunk and find_achievement_standard by focusing on cross-document search and listing result fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the search verb and scope but does not explicitly state when to use this tool over siblings or when not to use it. There is no mention of alternatives like list_official_sources or get_curriculum_chunk, so the agent must infer selection from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-candidatefind_achievement_standardget_coverage_reportget_curriculum_chunklist_official_sourcessearch_curriculumScored across 5 tools
The tools are mostly distinct: coverage report, source listing, search, chunk retrieval, and achievement standard lookup. However, search_curriculum and find_achievement_standard could overlap when searching for specific standards, though the latter is more targeted.
Tool names follow a consistent verb_noun pattern (get_, list_, search_, find_). Minor deviation: 'get_coverage_report' and 'get_curriculum_chunk' both use 'get' but target different resources, which is acceptable.
Five tools is well-scoped for a specialized curriculum server, covering search, retrieval, source listing, coverage reporting, and standard lookup without redundancy.
The surface covers core operations: listing sources, searching, retrieving chunks, and finding standards. Minor gaps like direct browsing of curriculum structure or filtering by grade/subject are not present, but the provided tools likely suffice for typical queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Read-only MCP server for the WebAssembly spec: instructions, types, sections, search, proposals.
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
