Skip to main content
Glama

Package HTML as SCORM (2004 or 1.2)

scorm_package
Destructive

Turns self-contained HTML, folders, ZIPs, or mobile-learning exports into SCORM 2004/1.2 packages any LMS can import, with offline asset inlining and milestone-based progress tracking.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoRaw HTML content to convert (e.g. the output of Claude Design). Provide this OR input_path.
batchNoTreat 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.
titleNoCourse / 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.
formatNoInput format. 'auto' (default) detects Claude Design .dc bundles by signature; override to force a pipeline.
base_urlNoBase 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).
languageNoContent language tag (BCP-47), e.g. 'fr-FR', 'en-US', 'it-IT'. Default: 'fr-FR'. Applied as <html lang> when the source declares none.
identifierNoManifest identifier. Auto-generated from the title if omitted.
input_pathNoAbsolute path to an HTML file on disk. Its folder is used to resolve relative assets. Provide this OR html.
output_dirNoDirectory to write the .zip package into. Defaults to $SCORM_OUTPUT_DIR or ~/scorm-packages.
vendor_cdnNoFor 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_scoreNoPass 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_versionNoSCORM 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_milestonesNoWhen 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_completionNoAlso report cmi.success_status='passed' when the module completes (equivalent to adding data-scorm-success="on-completion"). Default: false.
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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