这是一个只读 MCP 服务器，用于检索大韩民国 2022 年修订特殊教育课程中初中·高中的基础·共同·选择中心课程，并附有出处。
当前版本为 v0.1.0-candidate。官方原文不部署在存储库中，而是复现与告示·附册·文件哈希·页面位置关联的本地检索语料库。
所需工具为 Git 和 Node.js 20 或更高版本。下载存储库后，执行以下命令。
git clone <이 저장소의 GitHub URL>
cd korean-special-education-curriculum-mcp
npm install
npm run sources:prepare
npm run check
npm run test:mcpsources:prepare 会自动从公开 URL 下载可获取的资料并进行结构化处理。如果没有需要发布机构登录的可选补充资料，则仅输出警告并继续准备其余资料。服务器可用的实际范围及缺失资料可通过 get_coverage_report 确认。
面向首次安装用户的操作系统별连接方法和示例整理在 docs/USER_GUIDE.md 中。
Related MCP server: ClassCraftMCP
初中和高中
基础课程
共同课程
选择中心课程
教育部告示第 2022-34 号及后续修订告示
现行基准日为 2026-08-19，以国家教育委员会告示第 2026-2 号作为特殊教育基准线。为确认共同·选择中心普通教科的适用关系，同时收集第 2024-3 号。
准备 81 份官方来源：法定课程 35 份、解说 1 份、评价资料 17 份、研究·检查资料 28 份
现行法定范围 29 份：特殊教育附册 1·2·3 及适用于中·高中的普通教育课程附册 26 份
文件签名检查、SHA-256、最终 URL 及采集时间记录
使用 kordoc 进行 HWP/HWPX/PDF → Markdown·结构化分块转换
26,354 页、112,889 个分块的本地检索语料库
初中·高中及基础·共同·选择中心过滤器
区分法定原文·解说·成就/评价·研究资料的 materialKind 过滤器
包含来源 URL·告示编号·页码·目录路径的只读 STDIO MCP
npm install
npm run sources:prepare
npm run check
npm run test:mcp
npm run serve官方文档下载和提取结果属于 .gitignore 对象。再现信息记录在 sources/official/source-receipts.json 中。
法定课程和公开补充资料无需单独下载。npm run sources:prepare 会从官方 URL 下载、验证后转换。需要 Edueable 会员访问权限的资料为可选项，目录中的 manualAcquisition 记录了原始文件名和 ZIP 内部路径，自行获取相应原件并放置在 sources/official/files/ 中指定的英文文件名下，即可纳入完整语料库。缺失时，采集器会输出所需文件和目标名称，然后继续处理可自动采集的其余资料。
使用以下命令严格确认本地是否已准备全部资料。
npm run check:fulllist_official_sources：现行基准线、来源、准备状态和分块数量
get_coverage_report：现行法定原文和补充资料的准备·缺失状态
search_curriculum：按搜索词·学校级别·课程类型·教科·资料种类过滤搜索
get_curriculum_chunk：查询搜索结果中的原文上下文和位置
find_achievement_standard：成就标准代码搜索
作为本地 STDIO 服务器运行。构建后，在项目范围的 .codex/config.toml 或 Codex MCP 设置中使用以下命令。
node <absolute-project-path>/dist/src/server.jsCodex 项目设置示例如下。
[mcp_servers.korean-special-education-curriculum]
command = "node"
args = ["<absolute-project-path>/dist/src/server.js"]连接服务器之前，先执行一次 npm run sources:prepare 和 npm run build。
连接后，建议先按如下方式请求以确认范围。
특수교육 MCP의 get_coverage_report로 현재 수록 범위를 확인해줘.后续问题示例如下。
고등학교 기본 교육과정 국어 성취기준을 고시 원문, 쪽수, URL과 함께 찾아줘.
[12국어01-02]의 원문과 성취기준 해설을 구분해서 보여줘.
진로와 직업 과목에서 안전과 관련된 내용을 고시 원문만 대상으로 검색해줘.国家教育委员会告示第 2026-2 号附册 2 所准用的普通教育课程中，包含中·高中范围的附册 3·4·7·12·14·18·19·22·23~39·41 全部内容。现行法定原文 29 份在 get_coverage_report 中接受独立的完整性检查。此前告示 6 份仅用于变更历史和出处确认，不纳入基本搜索。
解说·评价·研究资料不具有与法定课程同等的效力，因此标记为单独的资料种类。索引范围包括国立特殊教育院的 2022 年特殊教育课程草案研究中·高中范围 26 种、2025 年国家课程特殊教育调查·检查报告书、评价指南和基础课程评价资料、2026 年高中成就水平资料、理疗·职业生活成就水平和最低成就水平保障指导资料。需要 Edueable 会员访问权限的资料仅由用户自行获取的原件在本地处理，不包含在 Git 中。所定义的特殊教育专用补充资料范围的已知缺失可在 get_coverage_report 中确认为 0 件。
本项目不是教育部·国家教育委员会·NCIC 的官方产品。官方文档遵循各原始来源的使用条件，本存储库的 MIT 许可证不适用于官方文档。详细信息请参阅 PROVENANCE.md、ACKNOWLEDGEMENTS.md、THIRD_PARTY_NOTICES.md。
错误报告和改进贡献方法请参阅 CONTRIBUTING.md，安全问题报告请参阅 SECURITY.md。
예: 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.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Read-only MCP server for the WebAssembly spec: instructions, types, sections, search, proposals.
Search and retrieve published Alkemata articles, pages, and guidance through a read-only MCP server.
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
