Enables the creation of Canvas Common Cartridge (.imscc) packages, allowing for the structured assembly of courses, modules, assignments, pages, and rubrics compatible with the Canvas Learning Management System.
Utilizes Instructure's canvas_cc framework to build standardized educational content cartridges that adhere to Canvas-profile Common Cartridge specifications.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@imscc-mcp Create a Canvas cartridge for 'English 101' including a rubric and two assignments."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Repo: https://github.com/InquiryInstitute/imscc_mcp
MCP server that builds Canvas Common Cartridge (.imscc) packages using Instructure’s Ruby gem canvas_cc. Cartridges are Canvas-profile CC files; many LMSes (including Populi) can import valid Common Cartridge 1.x zip/imscc.
Wiki/lesson pages from canvas_cc are type="webcontent" in imsmanifest.xml. Populi often skips them (you may see two errors for two pages). Assignments typically use associatedcontent/imscc_xmlv1p1/learning-application-resource and import more reliably. When authoring from imscc_template, run assemble-spec.mjs --populi to omit wiki pages and wiki module items; see docs/POPULI.md there.
Node.js ≥ 18
Ruby + Bundler
From this repo root: bundle install (installs gems into vendor/bundle per .bundle/config)
Related MCP server: canvas-mcp
cd ~/GitHub/imscc_mcp
bundle install
npm install
npm run buildbundle install
npm install
npm testRuns integration checks on ruby/build_cartridge.rb: successful builds produce a ZIP with imsmanifest.xml; invalid specs are rejected.
node dist/index.jsPoint command at node and args at the absolute path to dist/index.js after npm run build. No env vars are required.
Tool | Purpose |
| Build |
| Minimal JSON example for |
| Check |
| Links to |
output_directory: absolute path; created if missing.
course.title: required.
Assignments — Supported: groups, points, submission_types (e.g. online_text_entry, online_upload), due dates, HTML body. Link a rubric with rubric_identifier (must match a rubrics[].identifier), plus optional rubric_use_for_grading / rubric_hide_score_total.
Rubrics — rubrics[] with identifier, external_identifier (defaults to identifier), title, optional points_possible, and criteria[] each with id, description, points, and ratings[] (id, description, points, criterion_id matching the criterion id).
Slides / decks — There is no separate “slides” type. Package files (e.g. .pptx, .pdf) under files[] with identifier, file_path (path inside the course files tree), and file_location (absolute path on the machine that runs the build). Optionally add a module item with content_type Attachment and identifierref set to the file’s identifier (see canvas_cc module item types).
Module items — e.g. WikiPage + identifierref matching a page identifier, or ExternalUrl + url.
Assignments → groups — assignment_group_identifier_ref must match an assignment group identifier.
Importer support (Canvas vs Populi vs others) varies; test imports on your LMS.
For types not yet mapped in ruby/build_cartridge.rb (quizzes, question banks, full LTI, etc.), extend the script using the canvas_cc README.
MIT
Build a Canvas Common Cartridge (.imscc) using the Ruby canvas_cc gem. Requires Ruby+Bundler and bundle install in the imscc-mcp repo. Output is a Canvas-flavored CC file (often importable into Canvas, Populi, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | identifier, file_path, file_location (local path to copy) | |
| pages | No | Wiki pages: identifier, page_name, body, workflow_state? | |
| course | Yes | Course metadata passed to canvas_cc | |
| folders | No | ||
| rubrics | No | Canvas rubrics: identifier, external_identifier?, title, criteria[].id, criteria[].ratings[]; link from assignments via rubric_identifier | |
| assignments | No | assignment_group_identifier_ref, optional rubric_identifier + rubric_use_for_grading; submission_types per canvas_cc | |
| discussions | No | ||
| canvas_modules | No | Modules; module_items use content_type WikiPage|ExternalUrl|… | |
| output_directory | Yes | Absolute directory where the .imscc file will be written (created if needed) | |
| assignment_groups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses prerequisites and output format, but lacks details on side effects, error handling, or behavior with missing parameters. It adds some value beyond the schema.
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, each delivering essential information: purpose, prerequisites, and output. No filler or 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?
Given the tool's complexity (10 parameters, nested objects, no output schema), the description is incomplete. It does not mention return value, error conditions, or how the parameters are used to generate the cartridge.
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 description does not address any parameters despite 70% schema description coverage. It adds no meaning beyond the schema, which already has terse descriptions for most parameters. The tool has 10 parameters with nested objects, so more guidance is needed.
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 builds a Canvas Common Cartridge (.imscc) using the Ruby canvas_cc gem. It specifies the output type and distinguishes itself from sibling tools (reference, check, example) which serve different purposes.
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 implies when to use the tool (to create an .imscc file) and mentions prerequisites (Ruby+Bundler and bundle install). It does not explicitly discuss alternatives or exclusions, but the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pointers to upstream canvas_cc documentation and the IMS CC / Canvas relationship.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It does not state that the tool is read-only, non-destructive, or any other behavioral traits beyond pointing to documentation. This leaves the agent uncertain about side effects or safety.
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 a single, concise sentence that efficiently conveys the tool's purpose with no unnecessary words.
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 tool has no parameters, no output schema, and a straightforward purpose as a reference, the description is complete enough for an agent to understand its role without additional detail.
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 fully covered (100%), so the baseline is 4. The description adds no param info, but none is needed since there are no parameters.
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 provides pointers to upstream documentation and explains the IMS CC/Canvas relationship, which distinguishes it from sibling action-oriented tools like imscc_build_cartridge. However, it lacks a specific action verb like 'list' or 'get', reducing clarity slightly.
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?
No guidance on when to use this tool versus alternatives. The sibling tools are listed but no comparison or context is provided for selecting this reference tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify Ruby, Bundler, and canvas_cc are available (bundle exec) from the imscc-mcp installation directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the tool verifies availability but does not mention whether it modifies state, output format, side effects, or required permissions. This leaves agents uncertain about the tool's 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 a single, precise sentence with no waste. It is well-structured and front-loads the action and target.
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 tool has no parameters, no output schema, and no annotations, the description is minimal. It adequately states the check but lacks details on output format or behavior, leaving gaps for an agent to infer.
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 has zero parameters, so no parameter explanation is needed. Baseline is 4, and the description adds no further parameter information, which is appropriate.
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 verifies availability of Ruby, Bundler, and canvas_cc from a specific directory. It uses a specific verb ('Verify') and resource ('availability'), distinguishing it from sibling tools like imscc_build_cartridge.
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 implies usage when checking environment dependencies but does not explicitly state when to use it vs alternatives, nor does it mention prerequisites or conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a minimal JSON example you can adapt for imscc_build_cartridge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description accurately indicates a read-only, side-effect-free operation by stating 'returns an example'. It does not disclose more details, but the nature of returning static data is inherently transparent.
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?
Single sentence that front-loads the action and purpose with no wasted words.
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 zero parameters, no output schema, and a simple task, the description fully explains what the tool does and how to use it in context of sibling tools.
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?
No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4. The description does not add parameter info, but none is needed.
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 returns a JSON example and explicitly links it to imscc_build_cartridge, distinguishing it from sibling tools like imscc_build_cartridge (which likely creates) and imscc_check_environment (which checks environment).
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 implies usage before imscc_build_cartridge to get a template, but does not explicitly state when to avoid or provide alternative tools. It gives good context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0imscc_build_cartridgeimscc_canvas_cc_referenceimscc_check_environmentimscc_example_specEach tool has a clearly distinct purpose: building the cartridge, providing documentation, checking environment prerequisites, and supplying an example spec. No overlap exists.
All tools share the 'imscc_' prefix, but the naming pattern is not fully consistent: 'build_cartridge' and 'check_environment' are verb_noun, while 'canvas_cc_reference' and 'example_spec' are noun phrases. However, the names are still readable and clearly indicate tool function.
With 4 tools, the server is well-scoped for its purpose of building IMSCC files. Each tool serves a necessary step in the workflow, and there is no bloat or shortage.
The toolset covers the core workflow: environment check, reference, example, and build. Minor gaps exist, such as a tool to validate or inspect a built cartridge, but the surface is adequate for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Canva MCP server connects AI assistants (like Claude, ChatGPT, and Cursor) to Canva's API, enabling them to create and manage designs directly within chat conversations. Key capabilities include generating new designs from prompts, autofilling templates, searching and resizing existing designs, importing files from URLs, exporting designs as PDFs or images, and managing folders and comments without switching between tools.
MCP server for the Inistate platform: module discovery, entry management, and activity submission.
A MCP server built for developers enabling Git based project management with project and personal…
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CastaliaInstitute/imscc_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
