Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Delete Module

delete_module
DestructiveIdempotent

Preview and permanently remove a Canvas course module and its item links while keeping linked pages, assignments, and files intact in the course.

Instructions

Delete a module. Two-step: preview first, then confirm with the token.

Permanently removes the module and its item links. The linked content (pages, assignments, files, etc.) is not deleted and stays in the course.

Input Schema

NameRequiredDescriptionDefault
module_idYesModule ID to delete
course_identifierYesCourse code or Canvas ID
confirmation_tokenNoToken from the preview call; omit to preview

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.12.0
    • addedInput schema / properties / confirmation_token
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Token from the preview call; omit to preview"
+}
  2. Changed1 schema field changedv1.10.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  3. Changed9 schema fields changedv1.8.0
    • 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 / module_id / description
      Added value: +"Module ID to delete"
    • removedInput schema / properties / module_id / title
      Removed value: -"Module Id"
    • removedInput schema / title
      Removed value: -"delete_moduleArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"delete_moduleOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  4. Addedv1.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by spelling out the blast radius: the module and its item links are gone, but the underlying pages, assignments and files remain in the course. That distinction is the single most important thing an agent needs before calling a destructive tool, and the two-step token flow adds a further safety behavior not encoded in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, no waste, and the irreversible nature and workflow are front-loaded before the caveat about retained content.

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 destructive tool with no output schema, the description covers permanence, cascade scope and the confirmation workflow. The one remaining gap is that it doesn't say what the preview step returns (an item count? a warning?), which an agent would want before committing to the second call.

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 coverage is 100% and the schema already documents module_id, course_identifier and confirmation_token ('Token from the preview call; omit to preview'). The description restates the token workflow in prose without adding format details, so the schema is doing the heavy lifting and baseline 3 applies.

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?

States a specific verb and resource ('Delete a module') and immediately defines scope: 'Permanently removes the module and its item links.' The clarification that linked content (pages, assignments, files) survives distinguishes it from the sibling delete_module_item and from generic deletion tools.

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?

'Two-step: preview first, then confirm with the token' tells the agent exactly how to sequence the call. That is strong procedural guidance, but it never names an alternative (e.g. delete_module_item for removing a single item, or update_module as a non-destructive path), so the when-not-to-use case is implicit.

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

Deploy Server

Other Tools