This server converts HTML-based learning modules into SCORM 2004 or 1.2 packages for any LMS. It accepts self-contained HTML, folders/ZIPs, Claude Design .dc bundles, and Teach on Mars exports. All assets (CSS, JS, images, fonts) are inlined as data URIs for offline use. A runtime is injected to track completion, progress, time spent, and resume. Milestones are auto-generated from document structure or defined via data-jalon attributes (view, click, ended). An optional mastery_score enables score-based success (passed/failed), and scores can be reported via API or events. Packages include validated manifests with ADL schemas, and a local test harness is provided. Batch processing, CLI, a web UI, and a library API (buildPackage()) are available. The tool runs locally with no data collection, optionally setting output directory and returning metadata. It also handles CDN libraries in Claude Design bundles and applies missing BCP-47 language tags.
Turn self-contained HTML, a Claude Design
.dcbundle or a mobile-learning platform content export (Excel activity templates + media) into a SCORM 2004 (or 1.2) package ready to import into any LMS — assets inlined for 100% offline, completion / progress / score tracking injected, ADL schemas bundled.
The bundled local harness (scorm-test-harness.html) playing a package: progress 0 → 100%, completion, and the live LMS API-call log (0 errors). Illustration.
An MCP server exposing three tools: scorm_package converts a finished HTML learning module into a .zip (PIF) any SCORM-compliant LMS can import, scorm_validate checks any existing SCORM zip (made by any tool) and explains exactly why an LMS would reject it, and scorm_selftest is a 1-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 URIs → runs 100% offline.
Injects a small runtime that reports completion, progress (%) and time spent, with resume across sessions.
Generates the manifest and bundles the 15 official ADL XSD schemas — the manifest is validated against them (real conformance, not just "well-formed").
325/325 automated checks green: 23 converter · 15 runtime · 15 MCP · 1 schema conformance (xmllint) · 6 security · 11 features · 13 auto-milestones · 21 V2 (bundle / .dc / score) · 10 output-dir · 9 tracking-signal · 32 hardening · 29 SCORM 1.2 · 12 CLI/batch · 16 web UI · 44 mobile-learning migration · 35 package validation · 33 question-level interactions — plus 6 bonus strict-runtime checks (scorm-again).
SCORM Cloud (real LMS): imports cleanly (recognized as SCORM 2004 4th Ed., "manifest looks great"), and the dashboard reports completion = complete, success = passed, time tracked.
Related MCP server: Connectry Architect Cert
Input ( | Handling |
A single self-contained | assets inlined, runtime injected — v1 path |
A folder or | whole tree preserved; entry HTML inlined; manifest lists every file |
A Claude Design | auto-detected; CDN libs (React/Babel…) vendored offline via |
A mobile-learning platform content export (Excel activity templates + | auto-detected; an interactive HTML course is rebuilt from the templates — info / transition / flash cards, quiz questions, media codes ( |
Pass a .dc bundle as its folder or .zip (not the lone .dc.html, which is inert without its siblings).
Set mastery_score (0..1) to enable score-based success and add sequencing objectives 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 these to cmi.score.*, sets success_status = passed/failed against mastery_score, and reports completion/progress. (dc:* event names are accepted as aliases.)
Question-level tracking (v2.3) — report each answer as a cmi.interactions record, so the LMS gradebook shows which questions were missed, not just the 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, incorrect vs wrong) and best-effort by design: an LMS that refuses interaction writes gets a logged warning and the session carries on. Quizzes generated by the mobile-learning migration report their interactions automatically — one record per question, with the question text, the learner's answer, the expected answer and the latency.
SCORM 1.2 — pass scorm_version: "1.2" and you get a 1.2 manifest (validated
against the bundled 1.2 XSDs, with adlcp:masteryscore when mastery_score is
set). The injected runtime is adaptive: it speaks to whichever API the hosting
LMS exposes (API_1484_11 or API), maps the data model (single
lesson_status, 0-100 score, HH:MM:SS session time, 4096-char suspend data)
and never downgrades a passed status.
Batch — batch: true treats input_path as a directory of courses (each
sub-directory, .zip or .html = one course). One package per course, one
consolidated batch-report.json, and a broken course never sinks the others.
CLI — no MCP client required:
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 an .html or .zip, pick the SCORM
edition and an optional pass mark, download the package. Runs entirely on your
machine; nothing is uploaded 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 …Diagnostic — the scorm_selftest MCP tool packages a constant built-in HTML
and reports version, duration and output path: it separates "server broken"
from "input problem" in one second.
"Why does my LMS reject this zip?" — scorm_validate answers it for any SCORM package, not only those produced 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 (detects the classic "zipped the folder instead of its contents" mistake and says how to fix it), well-formed manifest, SCORM edition detection (2004/1.2), launchable organization/item/resource chain, launch file and every <file href> present in the archive (case-only mismatches flagged — they work on Windows and fail on Linux LMS servers), and full XSD validation against the official ADL schemas — using the package's own XSDs first and falling back to the embedded copies, so packages that ship without schemas validate too. Exit code 0/1 for CI pipelines; also exposed as the scorm_validate MCP tool and the validatePackage() library API.
https://scormpackager.vercel.app — drop a course, pick the SCORM edition, download the package. Files are processed in memory and never stored, but they do travel to a server; for real work use the local options below, where nothing leaves your machine (and there is no 4 MB limit).
Download scorm-mcp-server-x.y.z.mcpb from the Releases, then in Claude Desktop → Settings → Extensions, drag-drop the .mcpb, pick an output folder, and enable it.
No install step: add this to your client's MCP 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).
git clone <this-repo> && cd scorm-mcp-server
npm install # dist/ is prebuilt; npm run build is optionalThen point the config at node /ABSOLUTE/PATH/scorm-mcp-server/dist/index.js.
Restart Claude. The scorm_package tool is now available.
In a conversation: build your module with Claude Design, then say "package this module as SCORM." Claude calls scorm_package and returns the path to the .zip.
You don't have to prepare anything: if your HTML declares no milestone, the packager auto-generates them from the document structure (sections → articles → headings, capped at 8, trigger view). Plain HTML gets meaningful progress out of the box. Disable with auto_milestones: false. Want success_status = passed on completion without touching the HTML? Pass success_on_completion: true.
Mark the meaningful steps directly in your HTML — explicit milestones always take precedence over auto-generation. The runtime computes progress_measure = milestones_reached / total, and sets completion_status = "completed" once all are reached.
Attribute | Effect |
| declares a milestone |
| reached when scrolled into view (default) |
| reached on click |
| reached when a 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 micro-module. Resume is automatic (cmi.suspend_data + cmi.location); progress never regresses.
Programmatic milestones — window.SCORM2004.reach("quiz-passed") works even if the id has no data-jalon element: unknown ids are declared on the fly and count in the total. To register one before it's reached (accurate denominator), use window.SCORM2004.declare("quiz-passed") early. Both survive resume.
Success status (opt-in) — add data-scorm-success="on-completion" on any element (e.g. <body>) and the runtime also sets cmi.success_status="passed" when the module completes. Without it, success_status is never written.
Language — the tool's language (BCP-47, default fr-FR) is applied as <html lang="…"> when the source HTML doesn't declare one.
Security — asset references are confined to the module folder: ../ or absolute paths outside it are never inlined (a warning is emitted instead).
Open scorm-test-harness.html via a tiny local server and drop a generated .zip into it:
python3 -m http.server 8000 # then open http://localhost:8000/scorm-test-harness.htmlYou'll see live progress %, completion, and the full log of LMS API calls (0 errors expected).
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.mjsRequirements: Node ≥ 20, and xmllint (libxml2-utils) for the schema test.
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)This extension runs entirely locally: no data collection, no telemetry, no third parties. The only network activity is downloading assets that your own HTML references, to embed them into the offline package. Full policy: 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
