Canvas MCP Server

Overview Schema Source Related Servers Discussions Admin

Create Module

create_module

Creates a module in a Canvas course, published by default or saved as a draft. Configure position, unlock date, prerequisites, and sequential progress to structure course content.

Instructions

Create a module in a course.

Modules are published by default, so the module (and any published items later added to it) is visible to students on creation, subject to unlock_at and prerequisites; pass published=False to build it as a draft.

Input Schema

Name	Required	Description
`name`	Yes	Module name
`position`	No	Position in module list (1-indexed)
`published`	No	Whether the module is published (default: True)
`unlock_at`	No	Unlock date/time (ISO 8601)
`course_identifier`	Yes	Course code or Canvas ID
`prerequisite_module_ids`	No	Comma-separated module IDs that must be completed first
`require_sequential_progress`	No	Students must complete items in order

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.10.0Aug 20, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changed19 schema fields changedv1.8.0Aug 10, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / course_identifier / description
```
Added value: +"Course code or Canvas ID"
```
- removedInput schema / properties / course_identifier / title
```
Removed value: -"Course Identifier"
```
- addedInput schema / properties / name / description
```
Added value: +"Module name"
```
- removedInput schema / properties / name / title
```
Removed value: -"Name"
```
- addedInput schema / properties / position / description
```
Added value: +"Position in module list (1-indexed)"
```
- removedInput schema / properties / position / title
```
Removed value: -"Position"
```
- addedInput schema / properties / prerequisite_module_ids / description
```
Added value: +"Comma-separated module IDs that must be completed first"
```
- removedInput schema / properties / prerequisite_module_ids / title
```
Removed value: -"Prerequisite Module Ids"
```
- addedInput schema / properties / published / description
```
Added value: +"Whether the module is published (default: True)"
```
- removedInput schema / properties / published / title
```
Removed value: -"Published"
```
- addedInput schema / properties / require_sequential_progress / description
```
Added value: +"Students must complete items in order"
```
- removedInput schema / properties / require_sequential_progress / title
```
Removed value: -"Require Sequential Progress"
```
- addedInput schema / properties / unlock_at / description
```
Added value: +"Unlock date/time (ISO 8601)"
```
- removedInput schema / properties / unlock_at / title
```
Removed value: -"Unlock At"
```
- removedInput schema / title
```
Removed value: -"create_moduleArguments"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"create_moduleOutput"
```
- addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```
Addedv1.3.0May 2, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare idempotentHint=false and destructiveHint=false, so the description carries the important side-effect disclosure: modules are published by default and therefore student-visible immediately, subject to unlock_at and prerequisites. This is exactly the kind of non-obvious consequence an agent needs. It stops short of noting permission requirements or that a failed partial create can't be retried idempotently, which the idempotentHint=false annotation implies.

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?

Front-loaded with the purpose, then the default-visibility behavior with the escape hatch (published=False) at the end. Every sentence carries information, though the middle sentence is long and packs three separate gating concepts (unlock_at, prerequisites, default publish) into one clause chain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter creation tool with no output schema, the description covers the one behavior that matters most (default visibility) and the draft escape hatch. What's missing is what comes back — whether the created module's ID is returned so the agent can chain into add_module_item — and any permission/enrollment requirement.

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?

Schema description coverage is 100%, so the baseline is 3; the description earns an increment by explaining the real consequence of the `published` flag — visibility to students on creation — rather than restating "Whether the module is published." It also contextualizes unlock_at and prerequisite_module_ids as gating conditions, though it adds nothing about position or require_sequential_progress beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ("Create a module in a course"), which is unambiguous and clearly distinct from update_module, delete_module, and add_module_item in the sibling list. It doesn't explicitly name those siblings, but the create/update/delete/item split is inferable from the name and description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implicitly clear from the creation verb, and there is one concrete usage hint — "pass published=False to build it as a draft" — for the draft workflow. However, it never addresses when to use this versus add_module_item (adding content to an existing module) or how it precedes update_module, and offers no prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Create Module

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools