h5p-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_h5p_typesA | List the H5P content types this server builds packages for: each one's library and pinned version, what it's for and, for the types that hold others (Question Set, Course Presentation), the types that go inside (parts). Pass type to get its fields: the shape of the content build_h5p takes for it, with each field's kind, whether it's required, its limits, its options and the HTML tags it allows. Buttons and messages aren't listed: build_h5p fills them in the package's language. Images and other media aren't supported yet. Read the fields of each type before writing its content, and of each part you put inside another. |
| build_h5pA | Build a content-only .h5p package (h5p.json and content/content.json, no libraries) from content written for one of list_h5p_types' types, in the shape its fields give. The content is checked first, with the rules a site applies when it deploys the package (required fields, kinds, limits, the HTML tags each text allows) and the type's own (a multiple choice with a right answer, a blank with its answer…); if anything is wrong nothing is written and the error lists what to fix. Plain text is escaped; where a field takes HTML, simple HTML with its allowed tags may be used. Buttons and messages are filled in the package's language. Writes /.h5p and, unless preview is false, .preview.html next to it: the content as a page to review before uploading. Confirm with the person before overwriting. The package plays only on a site with that type installed at that version; uploading it is another tool's job. |
| read_h5pA | Read what a local .h5p package holds: its type and version, title, language and its content, in the same shape build_h5p takes, so it can be reviewed, or changed and built again with build_h5p. Packages that bring their libraries are read too (their content only; libraries lists them). supported says whether build_h5p builds this type at this version. Only reads. |
| server_infoA | Show this server's name, version and data folder, and, for a server that needs programs installed apart, whether they're there. Contains no secrets. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: listing supported H5P types and their field schemas, building a package, reading an existing package, and reporting server metadata. There is no overlapping behavior that would make tool selection ambiguous.
Three core tools follow a clear verb_noun_h5p pattern (list_h5p_types, build_h5p, read_h5p), making their relationship obvious. server_info is a minor deviation, but the overall convention remains readable and predictable.
Four tools are well-scoped for a package builder: schema discovery, build, read, and server metadata. No tool feels redundant, and the surface is compact without being thin.
The core lifecycle of discovering types, building validated packages, and reading packages is covered. Upload/deployment is explicitly out of scope, but the surface otherwise lacks no obvious operation needed for content-only package work.