Преобразует самодостаточный HTML, бандл Claude Design
.dcили экспорт контента мобильной учебной платформы (шаблоны занятия Excel + медиа) в пакет SCORM 2004 (или1.2), готованный к импорту в любую LMS: ресурсы встроены для гарантированой 100% офлайн-работы, подклый чают отслеживание завершения / прогресса / оценки, добавлены inlude ADL-схемы.
[ OC
[
]
[) [![iadge]...
![???..]
Need ensure badges all retained; mark as code; I'll output them unchanged as source.
Let's output now, but be accurate.
We don't need to wrap in code fence. Just raw.
Let's compose final in Russian with markdown. We can omit the higher "переводы" until.
Let's ensure table rows still original | count. We'll craft.
Let's now write final:
Всё translated but code values unchanged.
There follow badges, etc.
Need adjust from previous draft to proper.
Let's produce final.# scorm-mcp-server
Преобрается самодостаточный HTML, бандл Claude Design
.dcили экспорт контента мобильной учебной платформы (шаблоны активностей Excel + медиа) в пакет SCORM 2004 (или 1.2), готовый к импорту в любую LMS: ресурсы встроены для 100% офлайн, внедрено отсмеживание завершения / прогреса / оценки, включены схемы ADL.
)
The bundled local harness (scol-test-harness) playing package: progress 0 → 100%, completion, and live LMS API-call log (0 errors). Illustration.
MCP-сервер Раскрывает three tools: scorm_package converts a complete a finished HTML learning module into a .zip (PIF) import by any SCORM-compatible LMS; scorm_validate checks any existing SCORM zip (made by any tool) and explains exactly why the LMS rejects it; scorm_selftest — a second health check.
Principle: WRAP, don't rewrite. Your HTML is preserved; the tool only:
Inlines every asset (CSS, @import, fonts, JS, images, srcset, favicons) as data URI → works 100% offline.
Add a small runtime that reports completion, progress (%) and time spent, with resume between sessions.
Creates the manifest and bundles the 15 official ADL XSD schemas — the manifest is checked against it (actual conformity, not just “getformed”).
325/325 automated tests: 23 конверter, 15 рантайм, 15 MCP, 1 конформство схеми (xmllint), 6 безопасности, 11 specials, 13 автоплоских вех, 21 V2 (бандл / .dc / оЧенка), 10 каталоговывода, 9 Signalтregervals, 32 Hardening, 29 SCO 1.2, 12 CLI/batch, 16 web UI, plus 44 mobile-learning migration, 35 package-validation, 33 question-level interactions — и 5 бонус-строгих проверок (scorm-again).
SCORM Cloud (real LX): imports clean, got recognized as SCORM 2004 4th Ed., and the dashboard shows > ; done = done, success = passed, time recorded.
Related MCP server: Connectry Architect Cert
Input ( | Handling |
One self-contained | объединстроены, рантайм внедрён — v1 путь |
Folder or | Your tree preserves; entry HTML inlined; manifest lists every file |
Claude Design | auto-detected; CDN-libraries (React/Babel…) download offline via |
Mobile-learning platform content export (Excel activity templates + | auto-defined; from templates rebuilds an interactive HTML course — information / intermediate / flash cards, quiz questions, code |
For a .dc bundle, submit a folder or .zip (not a lone .dc.html — without its sibling it's lazy).
Set mastery_score (0..1) to enable mark-based success and add sequencing assignments to the manifest. Report the score from your content in one line — no SCORM knowledge required:
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"));The runtime maps this to cmi.score.*, sets success_status = passed/failed as compared to master_score, and reports completion/progress. (dc:* event names are accepted as aliases.)
Track-level tracking (v2.3) — write each answer as a record cmi.interactions, so that the LMS report shows which questions missed, not just total:
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 } }));Dialect-aware (2004 learner_response/timestamp vs 1.2 student_response/time, invalid vs wrong) and best-effort by design: if LMS refuses interaction records, it writes a warning in the log and the session continues. Quizzes generated by the mobile-learning migration report interactions automatically — one record per question, with a question, the learner's answer, the expected answer, and latency.
Scorm 1.2 — pass scorm_version: "1.2" and get a 1.2 manifest (validated against the built-in 1.2 XSDs, use adlcp:masteryscore if mastery_score is set). The injected runtime is adaptive: it speaks to whatever API the LMS exposes (API_1484_11 or API), converts the data model (one lesson_status, 0-100 score, HH:MM:SS session time, 4096-character suspension data) and never downgrades a passed status.
Batch mode — batch: true treats input_path as a directory of courses (each subdirectory, .zip or .html is one course). One package per course, one common batch-report.json, and a broken course doesn't sink the others.
CLI — no MCP client needed:
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 opens a localhost page: drop the .html or .zip, choose the SCORM edition and optional passing grade, download the package. Everything runs only on your machine; nothing is loaded anywhere.
Library — buildPackage() is a public API for pipelines and SaaS backends:
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 …Diagnostics — the MCP tool scorm_selftest packages a constant built-in HTML and returns version, duration, and output path: it separates "server broken" from "input data problem" in a second.
“Why does my LMS return this zip?” — scorm_validate answers this for any SCORM package, not only made here, and the input is never modified:
npx -y scorm-mcp-server validate course.zip # human-readable report
npx -y scorm-mcp-server validate course.zip --json # machine-readableChecks: zip readability, imsmanifest.xml at the ROOT (catches the classic “zipped a folder rather than its contents” and tells how to fix it), manifest well-formedness, SCORM edition detection (2004/1.2), lauchable organization/item/resource chain, launch file and every <file href> in the archive (case-only mismatches are found — work on Windows and fails on Linux LMS servers), full XSD validation against the official ADL-схем — uses own package XSD first, and if missing uses embedded copies, so packages that don't carry schemas validate too. Exit code 0/1 for CI; also as an MCP tool scorm_validate and as a library API validatePackage().
https://scormpackager.vercel.app — course, choose SCORM edition, download package. Data processed in memory and not stored, but flows to server; use real tasks for the local variants below, where nothing leaves your machine (and no 4MB limit).
Download scorm-mcp-server-x.y.z.mcpb from Releases, then in Claude Desktop → Settings → Extensions, drag it in .mcpb, select the output folder, and enable it.
No installation: add this to the MCP client config (~/Library/Application Support/Claude/claude_desktop_config.json for Claude Desktop):
{
"mcpServers": {
"scorm": {
"command": "npx",
"args": ["-y", "scorm-mcp-server"],
"env": { "SCORM_OUTPUT_DIR": "/ABSOLUTE/PATH/scorm-packages" }
}
}
}Registry name: io.github.giacomomaria81/scorm-mcp-server (MCP registry))
###Variant C — from source (developer)
git clone <this-repo> && cd scorm-mcp-server
npm install # dist/ is prebuilt; npm run build is optionalPoint the config at node /ABSOLUTE/PATH/scorm-mcp-server/dist/in.js.
Restart Claude. The scorm_package tool is now available.
In conversation: build module in Claude Design, then say "Packify this module as SCORM." Claude invokes scorm_package and returns the path to the .zip.
You do not need anything to do: if your HTML does not contain a milestone, the packager auto-generates them from the file (sections → sections → headings, max 8, trigger view). Plain HTML gets meaningful progress "out of the box". Turn it off with auto_milestones: false. Gain success_status = passed to complete without changing HTML? Pass success_on_completion: true.
Mark meaningful steps directly in your HTML — explicit milestones always take priority over auto-generation. The runtime computes progress_measure = milestones_reached / total and, when all is complete, puts completion_status = "completed".
Attribute/Triger | Effect |
| "declares a milestone" |
| "reached when scrolled into view (default) |
| "reached on click" |
| "resent when video/audio ends" |
<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>Recommended: 4-8 milestones per module. Restore automatically (cmi.suspend-data + cmi.location); progress never regresses.
Programmatic milestones — window.SCORM2004.reach("quiz-passed") works even if the id does not have element with data-jalon: unknown ids are declared on-the-fly and count in total. To register one earlier (exact denominator), use window.SCORM2004.declare("quiz-passed") early. Both survive resume.
Success status (opt-in) — add data-scorm-success="on-completion" to any element (e.g. <body>), and the runtime will also set cmi.success_status="passed" when the module is complete. Without it, success_status is never written.
Язык — значение language инструмента (BCP-47, по умолчанию fr-FR) применяется как <html lang="…">, если исходный HTML не объявляет язык.
Безопасность — ссылки на ресурсы ограничены папкой модуля: ../ или абсолютные пути вне её никогда не встраиваются (вместо этого выводится предупреждение).
Откройте 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 и 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
