Verwandeln Sie eigenständiges HTML, ein Claude-Design-
.dc-Bundle oder einen Export einer Mobile-Learning-Plattform (Excel-Aktivitätsvorlagen + Medien) in ein SCORM-2004- (oder 1.2-) Paket, das in jedes LMS importiert werden kann — Assets werden für 100 % Offline-Nutzung inline eingebettet, Abschluss-, Fortschritts- und Punktestand-Tracking werden injiziert, ADL-Schemata sind enthalten.
Der mitgelieferte lokale Testrahmen (scorm-test-harness.html) spielt ein Paket ab: Fortschritt 0 → 100 %, Abschluss und das Live-Protokoll der LMS-API-Aufrufe (0 Fehler). Abbildung.
Ein MCP-Server, der drei Werkzeuge bereitstellt: scorm_package wandelt ein fertiges HTML-Lernmodul in eine .zip-Datei (PIF) um, die jedes SCORM-konforme LMS importieren kann; scorm_validate prüft jedes vorhandene SCORM-Zip (von welchem Werkzeug auch immer erstellt) und erklärt genau, warum ein LMS es ablehnen würde; und scorm_selftest ist ein 1-Sekunden-Gesundheitscheck.
Prinzip: EINHÜLLEN, nicht neu schreiben. Ihr HTML bleibt erhalten; das Werkzeug führt nur folgende Schritte aus:
Bettet alle Assets inline ein (CSS, @import, Schriftarten, JS, Bilder, srcset und Favicons) als Data-URIs → läuft 100 % offline.
Injiziert eine kleine Laufzeitumgebung, die Abschluss, Fortschritt (%) und aufgewendete Zeit meldet, mit Wiederaufnahme sitzungsübergreifend.
Erzeugt das Manifest und bündelt die 15 offiziellen ADL-XSD-Schemata – das Manifest wird gegen sie validiert (echte Konformität, nicht nur „wohlgeformt“).
325/325 automatisierte Prüfungen grün: 23 Konverter · 15 Laufzeit · 15 MCP · 1 Schema-Konformität (xmllint) · 6 Sicherheit · 11 Features · 13 Auto-Meilensteine · 10 V2 (Bundle / .dc / Score) · 10 Ausgabeverzeichnis · 10 Tracking-Signal · 32 Hardening · 29 SCORM 1.2 · 12 CLI/Batch · 16 Web-UI · 44 Mobile-Learning-Migration · 35 Paketvalidierung · 33 Fragen-Interaktionen — plus 6 Bonus-Prüfungen für die strenge Laufzeit (scorm-again).
SCORM Cloud (echtes LMS): importiert sauber (wird als SCORM 2004 4th Ed. erkannt, „Manifest sieht großartig aus“), und das Dashboard meldet Abschluss = vollständig, Erolg = bestanden, Zeit fässig.**s
Related MCP server: Connectry Architect Cert
Eingabe ( | |
Eine einzelT eigenständige | Assets inline eingebettet, Laufzeit injiziert – v1-Pfad |
Ein Ordner oder eine | Ganzer Baum erhaten; Einstieg-HTL inline; Manifist listet jede Datei auf |
Ein Claude-Design- | wirt auto-erkand; CDN-Bibliotheken (React/Babel…) offline einkebunden via |
Ein Export einer Mobile-Planning-Plattform (Excel-Aktvitätvorlagen + | auto-erkand; aum aktivinterative-TML-Kurs wird aus den Vorlagen neu erstellt – Info-, C-, n-Ein- Lernkarten, Quiz-Fragen, Media-Codes ( |
Übergeben Sie ein .dcbundle als Ordner oder .zip (nicht die einzelne .dc.html, die ohne ihre Geschwisterdeteien funktionslos ist).
Setzen Sie mastery_score (0..1) ein, um den Erfolg punktestandbasiert zu machen und dem Manifest Sequencing-Objectives hinzuzügen. Melden Sie den Punktestand aus Ihrem Inhalt in einer Zeile – ohne SCORM-Kenntnisse:
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"));Die Laufzeitumgebung bildet diese auf cmi.score.* ab, setzt success_status = passed/failed je nach mastery_score und meldet Abschluss/Fortschritt. (dc:*-Ereignisnamen werden als Aliase akzeptiert.)
Tracking auf Fragenebene (v2.3) – melden Sie jede Antwort als cmi.interactions-Datensatz, damit das Notenbuch des LMS zeigt, welche Fragen falsch waren – nicht nur die Gesamtzahl:
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 } }));Dialektbewusst (2004 learner_response/timestamp vs. 1.2 student_response/time sowie incorrect vs wrong) und bewusst bestmöglich: Lehnt ein LMS Interaktion-Schreibungen ab, gibt es eine protokollierte Warnung und die Sitzung läuft weiter. Von der Mobile-Learning-Migration erzeugte Quizzes melden ihre Interaktionen automatisch – ein Datensatz pro Frage, mit Fragetext, Antwort des Lerners, erwarteter Antwort und Latenz.
SCORM 1.2 – übergeben Sie scorm_version: "1.2" und Sie erhalten ein 1.2-Manifest (validiert
gegen die mitgelieferten 1.2-XSDs, mit adlcp:masteryscore, wenn mastery_score gesetzt ist). Die injizierte Laufzeitumgebung ist adaptiv: Sie spricht mit jeder API, die das hostende LMS bereitstellt (API_1484_11 oder API), bildet das Datenmodell ab (einzelner lesson_status, Punktestand 0–100, Sitzungszeit HH:MM:SS, 4096 Zeichen Franklin suspend-data) und stuft einen passed-Status nie ab die.
Batch – batch: true behandelt input_path als Verzeichnis mit Kursen: Jedes Unterverzeichnis, jede .zip- oder .html-Datei = ein Kurs. Ein Paket pro Kurs, ein gemeinsamer batch-report.json, und ein defekter Kurs bringt die anderen nie zu Fall.
CLI – kein MCP-Client nötig:
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 öffnet eine Localhost-Seite: Ziehen Sie eine .html- oder .zip-Datei hinein, wählen Sie die SCORM-Edition und eine optionale Bestehensgrenze aus, laden Sie das Paket herunter. Läuft vollständig auf Ihrem Gerät – es wird nichts nach draußen übertragen.
Bibliothek – buildPackage() ist eine öffentliche API für Pipelines und 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 …Diagnose – das MCP-Werkzeug scorm_selftest verpackt eine fest eingebaute HTML und meldet Version, Dauer und Sausgabepfad:** es trennt „Server kaputt" von „Problem mit der Eingabe" in einer Sekunde.
„Warum führt das LMS dieses Paket ab?" – scorm_validate benantworte das für jedes SCORM-Paket zugund der „IT mit** jedes", nicht nur den auf diese in die übere das and no ihn Eingabe nie verändert:
npx -y scorm-mcp-server validate course.zip # human-readable report
npx -y scorm-mcp-server validate course.zip --json # machine-readablePrüft: Zuständigkeit der ZIP, imsmanifest.xml im ROOT (erkennt den klassischen „Ordner statt des Inhalts gezippt"-Irrtum und sagt sag, wie man ihn behebt), wohlgeformtes Manifest, Erkennung der SCORM-Edition (2004/1.2), startbare Organization/Item/Ressource-Kette, Startdatei und jede <file href> im Archiv, (Groß/Klein-Schreidungsdifferenz-bezeichnung werden markiert – sie funktionieren unter Windows, aber scheiter auf Linux-Servern), und die volle XSD-Validierung gegen die offiziellen ADL-Schemata (pakets) – zuerst mit den XSDs des Pakets selbst, dann Fallback auf die eingebundene Kopie, sodass auch Pakte ohne mitgelieferSchemata validiert werden. Exit-Code 0/1 für build pipelines; auch als scorm_validate MCP-Tool und validatePackage() Library-API verfügbar.
https://scormpackager.vercel.app – legen Sie einen Kurs ab, wählen die SCORM-Edition aus, laden Sie das Paket herunter. Dateien werden nur im Arbeitsspeicher verarbeitet und nicht gespeichert, sie
aber auch zu einem Server übertragen; für ernsthafte Aufgaben nutzen Sie die lokalen Optionen unten, bei denen nichts die Maschine verlässt (und es kein 4-MB-Limit gibt).
Laden Sie scorm-pa cp-mcp-server-x.y.z.mcpb von Releases herunter und ziehen Sie es dann in Claude Desktop → Einstellungen → Extensions, wählen Sie einen Ausgabeordner und aktivieren Sie es.
Keine Installation erforderlich: Fügen Sie dies der MCP-Konfiguration Ihres Clients hinzu (~/Library/Application Support/Claude/klond_desktop_config.json bei 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 optionalKonfigurieren Sie anschließend: node /ABSOLUTE/PATH/scorm-mcp-server/dist/index.js.
Claude neu starten. Das Werkzeug scorm_package ist jetzt verfügbar.
Im Gespräch: Erstellen Sie Ihr Modul mit Claude Design und sagen Sie dann „Verpacke dieses Modul als SCORM.“ Claude ruft scorm_package auffort und liefert den Pfad zur .zip.
Sie müssen nichts vorbereiten: Wenn Ihr HTML keinen Meilenstein deklariert, generiert der Packager sie automatisch aus der Dokumentstruktur (Abschnitte → Artikel → Überschriften, begrenzt auf 8, Triggerung view). Reines HTML erhält so automatisch sinnvollen Fortschritt. Deaktivierbar mit auto_milestones: false. Möchten Sie success_status = "passed" sss beim Abschluss, ohne an die HTML zu gehen? Über es success_on_completion: true ein.
Markieren Sie die sinnvollen Schrittstage mit no in Ihrem HTML – explizite Meilensteine haben immer gegen über automatisch. Die Laufzeitumgebung berrechnet progress_measure = thruched / total`` und setzt beim Veraban complection_status = "completed"` – sobald all ereicht sind.
Attribut | Wirkung |
| deklariert einen Meilenstein |
| erreicht, wenn in den handle hineingescrollt wird (Standard) |
| erreicht beim Klick |
| erreicht, wenn ein Video/Auster endet |
<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>Empfohlen: 4–8 Meilensteine auf jeden fall pro MikroModul. Automation (cmi.suspend_data + cmi.location); je Fortschrittgeht nichts zuruk.
Programmgesteuerte Meilensteine – window.SCORM2004.reach("quiz-passed") funktioniert auch, when die ID kein data-jalon- Eement except: Unbekannte IDs werden in der Flucht deklariert and zählen in der Gesamtsumme. Um eine vor their ereichung zu regstrieren (genaues Denominator), registrieren Sie window.SCORM200.dedeclare("quiz-passed") früh. Beide overstehende navigation.
Rolgreichster Status (opt-in) – Fügen Sie data-scorm-success="on-completion" auf beliebigen Element ein (z. B. <body>) und die Laufzeit setzt auch cmi.success_status="passed", wenn das Modul abgeschlossen ist. Ohne zu wird success_status nie geschrieben.
Sprache — die language-Einstellung des Tools (BCP-47, Standardwert fr-FR) wird als <html lang="…"> verwendet, wenn das Quell-HTML keine Sprache angibt.
Sicherheit — Asset-Verweise sind auf den Modulordner beschränkt: ../- oder absolute Pfade außerhalb davon werden nie eingebettet (stattdessen wird eine Warnung ausgegeben).
Öffnen Sie scorm-test-harness.html über einen kleinen lokalen Server und legen Sie eine generierte .zip-Datei hinein:
python3 -m http.server 8000 # then open http://localhost:8000/scorm-test-harness.htmlSie sehen in Echtzeit den Fortschritt (%), den Abschlussstatus und das vollständige Protokoll der LMS-API-Aufrufe (0 Fehler erwartet).
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.mjsAnforderungen: Node ≥ 18 und xmllint (libxml2-utils) für den 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)Diese Erweiterung läuft vollständig lokal: keine Datenerfassung, keine Telemetrie, keine Drittanbieter. Die einzige Netzwerkaktivität ist das Herunterladen von Ressourcen, auf die Ihr eigenes HTML verweist, um sie in das Offline-Paket einzubetten. Vollständige Datenschutzerklärung: 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
