将自包含的 HTML、Claude Design
.dc包或移动学习平台内容导出（Excel 活动模板 + 媒体）转换为 SCORM 2004（或 1.2） 包，可直接导入任何 LMS——所有资源内联以实现 100% 离线，注入完成 / 进度 / 分数跟踪，并捆绑 ADL 架构。
内置的本地测试工具（scorm-test-harness.html）运行一个包：进度 0 → 100%，完成状态，以及实时的 LMS API 调用日志（0 个错误）。示意图。
一个 MCP 服务器，提供三个工具：scorm_package 将完成的 HTML 学习模块转换为 .zip（PIF），任何符合 SCORM 标准的 LMS 都可导入；scorm_validate 检查任何已有的 SCORM zip（无论由任何工具生成），并准确解释 LMS 为何会拒绝它；scorm_selftest 是一秒钟的健康检查。
原则：只做包装，不重写。 你的 HTML 被完整保留；工具只做以下事情：
将所有资源内联为（CSS、@import、字体、JS、图片、srcset、favicon）data URIs，实现 100% 离线运行。
注入一个轻量运行时，用来报告 完成、进度（%） 和 所用时间，并支持跨会话续学。
生成清单并随附 15 个官方 ADL XSD 架构——清单将针对这些架构进行验证（是真正的合规，而不仅仅是“格式良好”）。
325/325 项自动化检查全部通过：23 个转换器 · 15 个运行时 · 15 个 MCP · 1 个架构合规（xmllint） · 6 个安全 · 11 个功能 · 13 个自动里程碑 · 21 个 V2（捆绑包 / .dc / 分数） · 10 个输出目录 · 9 个跟踪信号 · 32 个加固 · 29 个 SCORM 1.2 · 12 个 CLI/批量 · 16 个 Web UI · 44 个移动学习迁移 · 35 个包验证 · 33 个题目级交互 — 外加 6 项额外的严格运行时检查（scorm-again）。
SCORM Cloud（真实 LMS）： 干净导入（被识别为 SCORM 2004 第 4 版，“清单看起来很棒”），仪表板显示 完成 = 已完成，成功 = 已通过，时间 = 已记录。
Related MCP server: Connectry Architect Cert
输入（ | 处理方式 |
单个自包含的 | 资源内联，注入运行时 — v1 路径 |
文件夹或 | 保留整个目录结构；入口 HTML 内联；清单列出每个文件 |
Claude Design | 自动检测；CDN 库（React/Babel…）通过 |
移动学习平台内容导出（Excel 活动模板 + | 自动检测；根据模板重新构建一个交互式 HTML 课程 — 信息 / 过渡 / 闪卡、测验题目、媒体代码（ |
请将 .dc 包作为其文件夹或 .zip 传入（不要传入单独的 .dc.html，因为它缺少同级的文件时没有存在）。
设置 mastery_score（0..1）即可启用基于分数的成功判定，并在清单中添加排序目标。用一行代码从内容中报告分数 — 无需任何 SCORM 知识：
window.SCORM2004.score(8, 0, 10); // raw, min, max
window.dispatchEvent(new CustomEvent("scorm:score", { detail: { raw: 8, min: 0, max: 10 } }));
window.dispatchEvent(new CustomEvent("scorm:progress", { detail: 0.5 })); // 0..1
window.dispatchEvent(new CustomEvent("scorm:complete"));运行时将这些映射到 cmi.score.*，并根据 mastery_score 设置 success_status = passed/failed，同时报告完成度/进度。（dc:* 事件名称可接受为别名。）
题目级追踪（v2.3） — 将每个答题作为一条 cmi.interactions 记录上报，这样 LMS 成绩册能显示具体哪些题目答错，而不只是总分：
window.SCORM2004.interaction({
id: "quiz1-q3", type: "choice",
description: "Which colour is the brand?",
learnerResponse: "Blue", correctResponse: "Red",
result: false, latencyMs: 12000,
});
// or, without touching the API:
window.dispatchEvent(new CustomEvent("scorm:interaction", { detail: { id: "q3", result: true } }));支持方言感知（2004 使用 learner_response/timestamp vs 1.2 使用 student_response/time，以及 incorrect vs wrong），并且采用尽力而为的设计：如果 LMS 拒绝写入交互记录，会记录一条警告，会话继续。由移动学习迁移生成的测验会自动上报其交互 — 每道题一条记录，包含题目文本、学习者答题、高亮正确答案和答题用时。
SCORM 1.2 — 传入 scorm_version: "1.2"，即可获得 1.2 清单（使用随附 的 1.2 XSD 验证，并在设置 mastery_score 时附带 adlcp:masteryscore）。注入的运行时是 自适应 的：它可以与宿主 LMS 暴露的任何 API（API_1484_11 或 API）通信，映射数据模型（单一状态的 lesson_status、0-100 分、HH:MM:SS 会话时间、4096 字符的挂起数据），并且绝不会将 passed 状态降级。
批量 — batch: true 将 input_path 视为课程目录（每个子目录、.zip 或 .html 都是一门课程）。每个课程生成一个包，生成一份汇总的 batch-report.json，而且一门课程损坏不会影响其他课程。
CLI — 不需要 MCP 客户端：
npx -y scorm-mcp-server ui # local drag & drop web UI
npx -y scorm-mcp-server pack course.html --title "My course"
npx -y scorm-mcp-server pack ./courses --batch --scorm-version 1.2
npx -y scorm-mcp-server validate pkg.zip # conformance-check an existing package
npx -y scorm-mcp-server selftest # 1-second health checkWeb UI — --ui 会打开一个 localhost 页面：放入 .html 或 .zip，选择 SCORM 版本和可选的及格分（pass mark），即可下载包。完全在你自己的机器上运行；不会上传任何内容到任何地方。
库 — buildPackage() 是一个用于流水线和 SaaS 后端的公开 API：
import { buildPackage } from "scorm-mcp-server";
const r = await buildPackage({ html, title: "My course", scormVersion: "1.2", masteryScore: 0.6 });
// r.zip (Buffer) · r.fileName · r.warnings · r.milestoneIds …诊断 — 的 scorm_selftest MCP 工具会将一个固定的内置 HTML 打包，并报告版本、耗时和输出路径：它能在 1 秒内区分“服务器问题”和“输入问题”。
“为什么我的 LMS 拒绝这个 zip？”— scorm_validate 会对 任何 SCORM 包给出答案，而不仅仅是此处生成的包，并且输入文件永远不会被修改：
npx -y scorm-mcp-server validate course.zip # human-readable report
npx -y scorm-mcp-server validate course.zip --json # machine-readable检查项包括：zip 可读性、imsmanifest.xml 是否在根目录（能检测出经典的*“把整个文件夹压缩成 zip 而不是文件夹内容”*的错误，并说明如何修复）、清单格式是否良好、SCORM 版本检测（2004/1.2）、可启动的 organization/item/resource 链、启动项以及归档中的每个 <file href> 是否存在（仅大小写不同的会标记出来 — 这种在 Windows 上没问题，但在 Linux 的 LMS 服务器上会失败），以及针对官方 ADL 架构的完整 XSD 验证 — 优先使用包自带的 XSD，次优使用内置副本，因此没有附带架构的包也能通过验证。退出代码 0/1 适合 CI 流水线使用；同时暴露为 scorm_validate MCP 工具和 validatePackage() 库 API。
https://scormpackager.vercel.app — 拖入课程，选择 SCORM 版本，下载包。
文件会在内存中处理，不会被存储，但确实会传输到服务器；真正的使用请用下面的本地方式，这样内容不会离开你的机器（也没有 4 MB 的限制）。
从 Releases 下载 scorm-mcp-server-x.y.z.mcpb，然后在 Claude Desktop → 设置 → 扩展程序 中拖放该 .mcpb 文件，选择输出文件夹并启用它。
无需安装步骤：在你客户端的 MCP 配置中加入以下内容（Claude Desktop 的 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"scorm": {
"command": "npx",
"args": ["-y", "scorm-mcp-server"],
"env": { "SCORM_OUTPUT_DIR": "/ABSOLUTE/PATH/scorm-packages" }
}
}
}注册表名称：io.github.giacomomaria81/scorm-mcp-server（MCP registry）。
git clone <this-repo> && cd scorm-mcp-server
npm install # dist/ is prebuilt; npm run build is optional然后将配置指向 node /ABSOLUTE/PATH/scorm-mcp-server/dist/index.js。
重启 Claude 后，scorm_package 工具即可使用。
在会话中使用：先用 Claude Design 构建模块，然后说 “把这个模块打包成 SCORM。” Claude 会调用 scorm_package 并返回 .zip 的路径。
你不需要做任何准备：如果 HTML 没有声明任何里程碑，打包器会根据文档结构 自动生成里程碑（sections → articles → headings，上限为 8 个，并在 view 时触发）。纯 HTML 也能获得有意义的进度。通过 auto_milestones: false 关闭。想要在不修改 HTML 的情况下设置 success_status = passed？传入 success_on_completion: true。
直接在 HTML 中标记有意义的步骤——显式声明的里程碑始终优先于自动生成。运行时计算 progress_measure = milestones_reached / total，并在全部达到后将 completion_status 设为 "completed"。
属性 | 效果 |
| 声明一个里程碑 |
| 滚动到视野内时达到（代码块 |
| 点击时达到 |
| 视频/音频播放完毕时达到 |
<section data-jalon="intro" data-trigger="view">…</section>
<button data-jalon="read-pitch" data-trigger="click">I read it</button>
<video data-jalon="demo" data-trigger="ended">…</video>建议：**每个微模块 4–8 个里程碑。续学是自动的（cmi.suspend_data + cmi.location）；进度永远不会倒退。
程序化里程碑** — window.SCORM. 即使 id 上没有带 data-jalon 的元素，window.SCORM. 也可以正常工作：未知 id 会被当场声明并计入总数。要在其达到之前进行注册（获得准确分母），请尽早使用 window.SCORM2004.declare("quiz-passed")。两者都能跨会话保留。
成功状态（可选择加入） — 在任何元素（例如 <body>）上添加 data-scorm-success="on-completion"，运行时也会在模块完成时将 cmi.success_status 设为 "passed"。如果不添加该属性，success_status 永远不会被写入。
语言 — 该工具的 language（BCP-47，默认 fr-FR) 会在源 HTML 未声明语言时被用作 <html lang="…">。
安全 — 资源引用被限制在模块文件夹内：../ 或指向其外部的绝对路径绝不会被内联（而是会发出警告）。
通过一个小型本地服务器打开 scorm-test-harness.html，然后把生成的 .zip 文件拖入其中：
python3 -m http.server 8000 # then open http://localhost:8000/scorm-test-harness.html你会看到实时的进度百分比、完成状态，以及 LMS API 调用的完整日志（预期 0 错误）。
npm install
npm run build # tsc -> dist/
npm test # 102 checks: converter + runtime + mcp + schema + security + v2 (xmllint required)
# bonus: validate against a strict independent SCORM 2004 runtime
npm i -D scorm-again && node test/scorm-again.test.mjs要求：**、** **Node ≥ 20**，以及用于 schema 测试的 xmllint（libxml2-utils`）。
src/ index.ts (MCP server + CLI) · converter.ts (inlining + manifest + zip) · runtime.ts (injected SCORM runtime) · validate.ts (package conformance checker) · tom.ts (mobile-learning migration) · ui.ts (local web UI)
dist/ compiled output (shipped)
schemas/ 15 ADL XSD (SCORM 2004 4th Ed.) + schemas12/ (4 XSD SCORM 1.2), bundled into every package
test/ 17 suites (converter / runtime / mcp / schema / validation / interactions / migration…) + fixtures
ARCHITECTURE.md design decisions, data flow, testing strategy
scorm-test-harness.html local browser SCORM player (fake LMS, no account)
manifest.json MCPB manifest (for building the .mcpb desktop extension)`地完全本地运行：不收集数据、没有遥测、不涉及任何第三方。唯一的网络活动是下载你自己的 HTML 所引用的资源，以便将它们嵌入离线包中。完整政策：PRIVACY.md。
Convert a self-contained HTML document, a folder, a .zip, a Claude Design (.dc) bundle OR a mobile-learning platform content export (Excel activity templates + media) into a SCORM package (.zip) — SCORM 2004 4th Edition by default, or SCORM 1.2 for legacy LMSs.
Use this to turn a finished learning module (for example HTML produced by Claude Design) into a file that any SCORM-compliant LMS can import. The conversion is faithful: the HTML is preserved, external assets are inlined as data URIs so the package runs 100% offline, and a small runtime is injected to report completion and progress.
MIGRATION FROM MOBILE-LEARNING PLATFORMS: if the input zip/folder contains Excel activity templates (mobile course cards, quiz games...) plus a media folder — the format produced by the platform's content export — the tool rebuilds an interactive HTML course from them (info/transition/flash cards, scored quizzes reporting cmi.score, media embedded, the platform's layout codes rendered) and packages it. No title needed: it is derived from the template file names. Combined with batch mode this migrates a whole course catalogue in one call.
PROGRESS / COMPLETION MODEL (milestones): The author can mark meaningful steps with data-jalon + optional data-trigger:
J'ai lu (counts on click)
... (counts when playback ends) AUTOMATIC FALLBACK: if the HTML declares NO milestone, they are generated automatically from the document structure (sections → articles → h2 → h3, capped at 8, trigger "view"). So plain HTML "just works" with meaningful progress — you do NOT need to ask the author to add attributes first. Explicit data-jalon attributes always take precedence (recommended for click/video steps). The runtime reports cmi.progress_measure = milestones_reached / total, and sets cmi.completion_status = "completed" once all milestones are reached. Progress and scroll position resume across sessions via cmi.suspend_data / cmi.location. Content can also call window.SCORM2004.reach(id) / declare(id).
Args:
html (string, optional): HTML content. Provide this OR input_path.
input_path (string, optional): path to an HTML file on disk. Provide this OR html.
title (string): course/module title shown in the LMS. Required for HTML inputs; optional for a mobile-learning Excel export (derived from the templates).
language (string, optional): BCP-47 tag, default 'fr-FR'.
identifier (string, optional): manifest id; auto-generated from title if omitted.
base_url (string, optional): base URL for resolving relative asset paths over the network.
output_dir (string, optional): where to write the .zip. Default: $SCORM_OUTPUT_DIR or ~/scorm-packages.
auto_milestones (boolean, optional, default true): auto-generate milestones when none are declared.
success_on_completion (boolean, optional, default false): also set cmi.success_status='passed' on completion.
scorm_version ('2004' or '1.2', optional, default '2004'): SCORM edition of the package. Choose '1.2' for older LMSs that reject 2004. The injected runtime is adaptive and works with both LMS APIs either way; this controls the manifest and bundled schemas.
mastery_score (number 0..1, optional): pass threshold; enables score-based success.
batch (boolean, optional): treat input_path as a DIRECTORY of courses (each sub-directory, .zip or .html = one course). Produces one package per course plus a consolidated batch-report.json; a broken course never blocks the others. The title argument becomes a prefix.
Returns JSON: { "output_path": string, // absolute path to the generated .zip "file_name": string, "scorm_version": "2004 4th Edition" or "1.2", "milestone_count": number, // milestones in the package "milestone_ids": string[], "milestones_auto": boolean, // true if they were auto-generated "size_bytes": number, "warnings": string[] }
Notes:
Validate the resulting package on SCORM Cloud (cloud.scorm.com) before production rollout.
Offline completion that syncs later is provided by the LMS mobile app downloading this package; verify your target LMS apps support offline SCORM.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | Raw HTML content to convert (e.g. the output of Claude Design). Provide this OR input_path. | |
| batch | No | Treat input_path as a DIRECTORY containing several courses (each sub-directory, .zip or .html file = one course). Produces one package per course plus a consolidated report. Course titles default to the folder/file name; `title` is used as a prefix. | |
| title | No | Course / module title, used as the manifest, organization and item title shown in the LMS. Required for HTML inputs; optional for a mobile-learning Excel export, where it is derived from the template file names. | |
| format | No | Input format. 'auto' (default) detects Claude Design .dc bundles by signature; override to force a pipeline. | |
| base_url | No | Base URL to resolve relative/root-relative asset references over the network (only needed if the HTML uses relative URLs and no input_path is given). | |
| language | No | Content language tag (BCP-47), e.g. 'fr-FR', 'en-US', 'it-IT'. Default: 'fr-FR'. Applied as <html lang> when the source declares none. | |
| identifier | No | Manifest identifier. Auto-generated from the title if omitted. | |
| input_path | No | Absolute path to an HTML file on disk. Its folder is used to resolve relative assets. Provide this OR html. | |
| output_dir | No | Directory to write the .zip package into. Defaults to $SCORM_OUTPUT_DIR or ~/scorm-packages. | |
| vendor_cdn | No | For Claude Design (.dc) bundles: download CDN libs (React/Babel…) into the package so it runs offline (via window.__resources, no source patch). Default: true. | |
| mastery_score | No | Pass threshold 0..1. Enables score-based success (passed/failed from cmi.score.scaled) and adds sequencing objectives to the manifest. Content reports the score via window.SCORM2004.score(raw,min,max) or a 'scorm:score' CustomEvent. | |
| scorm_version | No | SCORM edition of the produced package. '2004' (default, 4th Edition) or '1.2' for legacy LMSs. The injected runtime is adaptive and works with both LMS APIs; this choice controls the manifest and bundled schemas. | |
| auto_milestones | No | When the HTML declares no [data-jalon] milestone, auto-generate 'view' milestones from the document structure (sections, then articles, then headings; max 8). Default: true. | |
| success_on_completion | No | Also report cmi.success_status='passed' when the module completes (equivalent to adding data-scorm-success="on-completion"). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already flag this as non-read-only and destructive, the description adds substantial behavioral context: assets are inlined as data URIs for 100% offline operation, a runtime is injected for progress/completion reporting, auto-fallback milestone generation is explained, and batch mode ensures 'a broken course never blocks the others'. It also discloses suspend_data/location resumption and window.SCORM2004 reach/declare methods.
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 lengthy but well-structured with clear section labels (MIGRATION, PROGRESS/COMPLETION MODEL, Args, Returns, Notes). Every paragraph delivers distinct value—input types, milestone tagging, parameter detail, return schema, and validation advice. The only minor issue is length; a few redundant phrases could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, multiple input formats, a milestone system, and return-value expectations, this description is exceptionally complete. It covers the input types (including mobile-learning export), the progress/completion model with data-jalon and auto-fallback, batch isolation, the JSON return structure, and post-conversion validation advice (SCORM Cloud). It could mention format/vendor_cdn more, but the schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 14 parameters, but the description's Args section adds practical nuance: for scorm_version it explains the adaptive runtime and manifest/schema implications; for mastery_score it mentions window.SCORM2004.score() and CustomEvent; for batch it explains the prefix behavior. However, it omits format and vendor_cdn from the Args narrative, though they appear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Convert a self-contained HTML document, a folder, a .zip, a Claude Design (.dc) bundle OR a mobile-learning platform content export into a SCORM package (.zip)'. This clearly distinguishes it from the sibling scorm_selftest, which is for testing. The title 'Package HTML as SCORM (2004 or 1.2)' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to turn a finished learning module (for example HTML produced by Claude Design) into a file that any SCORM-compliant LMS can import.' It gives context for legacy LMSs ('Choose '1.2' for older LMSs that reject 2004') and batch usage, but does not explicitly name alternatives (e.g., scorm_selftest), leaving the contrast implied via the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnostic tool with NO arguments: packages a constant built-in HTML and reports version, duration and output path. Distinguishes 'server broken' from 'input problem' in one second. Writes one small file (selftest-scorm2004.zip) into the output directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it writes a specific file (selftest-scorm2004.zip) into the output directory, which complements the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true). It also mentions reporting version, duration, and output path, providing additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences effectively convey purpose, use case, and side effects. The key information is front-loaded, and every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description fully covers what it does, the output file, the reported data, and the time frame. There is no output schema, but the reporting details are sufficient. The description is complete for an agent to decide when and how to invoke it.
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 and the schema is empty with 100% coverage. The description explicitly states 'NO arguments', which is consistent and adds clarity for an agent, meeting the baseline for no-parameter tools.
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 is a diagnostic self-test: it packages a constant built-in HTML and reports version, duration, and output path. It distinguishes itself from the sibling tool by being diagnostic with no arguments, which is specific and unambiguous.
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 tool is positioned as a diagnostic to differentiate 'server broken' from 'input problem' in one second, giving a clear use case. However, it does not explicitly name the alternative (scorm_package) or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an EXISTING SCORM .zip (made by this tool or by ANY other authoring tool) is conformant and will import into an LMS — and if not, explain exactly why.
Use this when an LMS rejects a package, before uploading a package to production, or to audit a batch of courses received from a vendor. The input is never modified.
Checks performed:
the archive is a readable zip with imsmanifest.xml at its ROOT (detects the classic "zipped the folder instead of its contents" mistake and says how to fix it)
the manifest is well-formed XML and the SCORM edition is identified (2004 or 1.2)
an with a launchable exists, resolving to a scormType="sco" with an href
the launch file and every listed in the manifest actually exist in the archive (case-only mismatches are flagged: they work on Windows but fail on the Linux servers most LMSs run on)
the manifest validates against the official ADL XSD schemas (XSDs bundled in the package are used first; missing ones are supplied from the copies embedded in this tool, so packages that ship without schemas can still be validated). Requires xmllint; skipped with a warning otherwise.
Args:
input_path (string, required): path to the .zip to validate.
Returns JSON: { ok, scorm_version, title, entry_href, files_in_zip, checks: [{id, label, ok, detail}], errors, warnings, schema_validation }
| Name | Required | Description | Default |
|---|---|---|---|
| input_path | Yes | Path to the SCORM .zip file to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, and the description goes well beyond them by detailing exact checks performed, such as root-level imsmanifest detection, case-only mismatch flags, XSD validation strategy, and the xmllint dependency warning. It also explicitly states "The input is never modified," reinforcing the non-destructive behavior.
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 long but well structured with front-loaded purpose, a summary usage sentence, a bulleted list of checks, and a clearly labeled Args section. It is dense with useful information; a slight redundancy in the Args section prevents a perfect score.
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 send total parameter, no output schema, and the complexity of SCORM validation, the description is thorough. It explains what validation covers, how edge cases like casing mismatches are detected, and even describes the return JSON shape. An agent has everything needed to invoke the tool and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents input_path with a clear description. The description adds little beyond restating the path, which is expected at high schema coverage. No parameter semantics are missing from the schema, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: "Check whether an EXISTING SCORM .zip ... is conformant and will import into an LMS." It distinguishes the tool from siblings by emphasizing validation of existing packages, including those from other authoring tools, and by noting the input is never modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: when an LMS rejects a package, before uploading to production, or when auditing vendor courses. It does not name specific sibling tools or describe when NOT to use this tool, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The three tools map to clearly distinct roles: packaging source content into SCORM, validating an existing SCORM package, and running a server-side self-test. There is no meaningful overlap in inputs, purposes, or expected usage.
All tools share the scorm_ prefix and snake_case style, making them predictable. The slight deviation is that scorm_package and scorm_validate read as verb-first, while scorm_selftest reads as a noun, but the pattern is still easy to follow.
Three tools is well-scoped for this server's purpose: one to create packages, one to validate packages, and one to diagnose the environment. Each tool earns its place and the count is appropriate for the domain.
The toolset covers the full relevant workflow: converting content to packages, validating existing packages against SCORM standards, and self-testing when issues arise. Input flexibility, batch mode, and detailed validation reporting address the main gaps a SCORM authoring server could face.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Compiles structured specs into SCORM 1.2/2004 e-learning packages. 30 tools, quality gate, no LLM.
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
AI-powered LMS course builder: 89 tools, 17 skills, SCORM/xAPI export, agentic UI
Publish HTML from Claude or ChatGPT to a live URL with a QR code — no developer needed.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/giacomomaria81/scorm-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
