Canvas LMS MCP Server

Update Assignment

update_assignment

DestructiveIdempotent

Modify an existing Canvas assignment by course and assignment ID. Adjust due dates, points, description, submission types, or publish status.

Instructions

Update an existing assignment in a course.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New assignment name
`due_at`	No	New due date in ISO 8601 format (e.g. 2026-05-01T23:59:00Z)
`lock_at`	No	New date after which the assignment locks and stops accepting submissions, in ISO 8601 format. Must be after due_at when there is one
`course_id`	Yes	The Canvas course ID
`published`	No	Whether the assignment is published and visible to students
`unlock_at`	No	New date the assignment becomes available to students, in ISO 8601 format. Must be before due_at when there is one
`description`	No	New assignment description (HTML supported)
`assignment_id`	Yes	The Canvas assignment ID
`points_possible`	No	New maximum points
`submission_types`	No	New allowed submission types
`assignment_group_id`	No	New assignment group ID
`omit_from_final_grade`	No	Whether to leave this assignment out of the final grade calculation
`grade_group_students_individually`	No	For group assignments, whether each member is graded separately (false = one shared group grade)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.18.16Oct 15, 2026

addedInput schema / properties / lock_at

Added value: +{
+  "description": "New date after which the assignment locks and stops accepting submissions, in ISO 8601 format. Must be after due_at when there is one",
+  "type": "string"
+}

addedInput schema / properties / unlock_at

Added value: +{
+  "description": "New date the assignment becomes available to students, in ISO 8601 format. Must be before due_at when there is one",
+  "type": "string"
+}

Changed9 schema fields changedv1.18.15Oct 14, 2026

addedInput schema / properties / assignment_group_id / anyOf

Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]

removedInput schema / properties / assignment_group_id / type
```
Removed value: -"number"
```

addedInput schema / properties / assignment_id / anyOf

Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]

removedInput schema / properties / assignment_id / type
```
Removed value: -"number"
```

addedInput schema / properties / course_id / anyOf

Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]

removedInput schema / properties / course_id / type
```
Removed value: -"number"
```

addedInput schema / properties / grade_group_students_individually

Added value: +{
+  "description": "For group assignments, whether each member is graded separately (false = one shared group grade)",
+  "type": "boolean"
+}

addedInput schema / properties / omit_from_final_grade

Added value: +{
+  "description": "Whether to leave this assignment out of the final grade calculation",
+  "type": "boolean"
+}

addedInput schema / properties / published

Added value: +{
+  "description": "Whether the assignment is published and visible to students",
+  "type": "boolean"
+}

Changed1 schema field changedv1.18.11Sep 10, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv1.18.0May 25, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the agent knows this is a repeatable but destructive remote write. The description adds nothing beyond that — it never explains partial-update semantics (are omitted fields preserved or cleared?), what gets overwritten, or permission requirements. For a destructive tool with only a one-line description, this is a real gap.

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?

A single front-loaded sentence with zero padding; nothing is redundant. It is efficiently written, though its brevity here reflects under-specification rather than disciplined concision.

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

Completeness2/5

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

For a destructive 13-parameter mutation with no output schema, the description should at minimum say that fields are updated selectively, what happens to omitted values, and any constraints. It supplies none of that, leaving the agent to guess at update semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 13 parameters including the ISO 8601 date constraints and cross-field ordering rules (lock_at after due_at, unlock_at before due_at) are already documented in the schema. The description adds no parameter meaning at all, which lands it at the baseline 3.

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?

States a specific verb ("Update") plus resource ("assignment") and scope ("in a course"), which distinguishes it from create_assignment, delete_assignment and get_assignment in the sibling list. However it gives no hint of which of the 13 updatable fields are in play, so it is clear but generic.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites (e.g. required permissions, whether the assignment must be published), and no mention of alternatives such as create_assignment or update_module_item. The agent must infer everything from the verb alone.

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

Deploy Server

Update Assignment

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools