Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Delete Peer Review

delete_peer_review
Destructive

Unassign a peer reviewer from a submission by removing that specific peer-review relationship. Use it to strip an incorrect or withdrawn reviewer while keeping the submission and assignment intact.

Instructions

Remove a peer-review assignment — identified by its assessor_id/user_id pairing — from one submission, unassigning that reviewer; the submission and the assignment itself are untouched, only the peer-review relationship goes away. Returns a confirmation message; Canvas's own response body is discarded. This is a reversible relationship removal, not an irreversible content delete: re-create the assignment with create_peer_review, though the new review gets a new id and workflow_state starts over at "assigned". Find the reviewer's user_id to remove with list_peer_reviews or get_submission_peer_reviews. Requires instructor/TA permission in the course.

Input Schema

NameRequiredDescriptionDefault
user_idYesThe Canvas user ID of the reviewer to remove
course_idYesThe Canvas course ID
assignment_idYesThe Canvas assignment ID
submission_idYesThe Canvas submission ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.18.15
    • 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 / submission_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / submission_id / type
      Removed value: -"number"
    • addedInput schema / properties / user_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / user_id / type
      Removed value: -"number"
  2. Changed1 schema field changedv1.18.11
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv1.18.0

TDQS

A4.4/5.0
Behavior5/5

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

Despite annotations already marking destructiveHint=true and openWorldHint=true, the description adds substantial behavioral detail: only the peer-review relationship is removed, the submission and assignment remain untouched, Canvas's response body is discarded, and reversal creates a new id with workflow_state reset to assigned. This is exactly the kind of scope, side-effect, and permission context an agent needs.

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?

The description is front-loaded with the core removal action and then layers in scope, reversal, ID lookup, and permissions. Every sentence carries useful information, though it is denser and longer than strictly necessary for a four-parameter deletion tool.

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

Completeness5/5

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

With no output schema and only sparse annotations, the description carries the full burden well: it explains the mutation scope, return behavior, permission requirement, and reversal path. An agent has enough information to invoke it correctly without needing additional context.

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%, so all four parameters are already documented by the input schema, making 3 the baseline. The description adds little parameter-level detail beyond identifying user_id as the reviewer to remove, and its mention of an assessor_id/user_id pairing is slightly at odds with the schema, which exposes only user_id.

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?

The description states a specific verb and resource: remove a peer-review assignment from one submission, unassigning that reviewer. It also distinguishes the scope from content deletion and names the related create/list tools, so an agent can tell what this tool does versus siblings.

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?

It gives clear operational context: use list_peer_reviews or get_submission_peer_reviews to find the reviewer's user_id, and re-create with create_peer_review if needed. It also states the instructor/TA permission requirement. It does not explicitly state when-not-to-use conditions, so it falls short of the top score.

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