Canvas LMS MCP Server

Comment on Submission

comment_on_submission

Destructive

Add a text comment to a Canvas submission without changing its grade or score. Use it to leave feedback or reply to a student's comment on a course assignment submission.

Instructions

Add a text comment to a submission and return the updated Canvas submission object, with the new entry appended to submission_comments. Not idempotent: each call posts another comment rather than editing or replacing a prior one, so a retried call leaves duplicate comments behind instead of one. This only adds a comment — it never changes grade or score; use grade_submission for that, on the same course_id/assignment_id/user_id. Use list_submission_comments_needing_attention to find submissions where the student's most recent comment has not yet been answered by staff. Permission is looser than grade_submission's: the submission's own student and any peer reviewer assigned to it can comment without grading rights; anyone who can grade can also comment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "course_id": "<course_id>",
      "assignment_id": "<assignment_id>",
      "user_id": "<user_id>",
      "comment": "<comment>"
    },
    "name": "comment_on_submission"
  }
}

Input Schema

Name	Required	Description
`comment`	Yes	The comment text to add
`user_id`	Yes	The Canvas user ID
`course_id`	Yes	The Canvas course ID
`assignment_id`	Yes	The Canvas assignment ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.18.15Oct 14, 2026

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 / 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"
```

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

A4.6/5.0

Behavior5/5

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

Annotations only flag destructiveHint/openWorldHint; the description adds the crucial non-idempotency warning (retries leave duplicate comments), the guarantee that grade/score are untouched, and the exact permission model versus grading rights. This is context beyond what the structured fields convey.

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 core action and non-idempotency warning are front-loaded and every sentence carries information. It is somewhat dense in the middle (permission clause), but no sentence is filler.

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?

For a 4-param mutation with no output schema, the description covers return shape, idempotency, side effects, permissions, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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 in-schema. The description only echoes course_id/assignment_id/user_id in the grade_submission cross-reference and adds no new format or constraint semantics, so the 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?

The first sentence states a specific verb and resource ('Add a text comment to a submission') and describes the return value (updated submission object with the new entry appended to submission_comments). It also explicitly contrasts with grade_submission, so an agent can distinguish it from the nearest sibling.

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

Usage Guidelines5/5

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

It explicitly routes the agent: use grade_submission to change grade/score, and use list_submission_comments_needing_attention to find unanswered comments. It also spells out who is permitted to comment, which determines whether a call is even viable.

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

Deploy Server