Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update Discussion

update_discussion
Destructive

Update an existing discussion topic in a course — title, message, published state, require_initial_post, delayed_post_at, or is_announcement — and return the updated topic; only the fields you pass are changed, the rest keep their current…

Instructions

Update an existing discussion topic in a course — title, message, published state, require_initial_post, delayed_post_at, or is_announcement — and return the updated topic; only the fields you pass are changed, the rest keep their current value. Course-scoped only: there is no update tool for group discussions, though list_group_discussions and get_group_discussion can still read them. Setting is_announcement: true asks Canvas to turn the topic into an announcement, but Canvas silently keeps it a plain discussion topic (HTTP 200, no error) if the caller lacks announcement-create permission in the course — this tool then throws instead of reporting success, naming the topic ID so you can check it with list_discussions or get_discussion. Use create_discussion to make a new topic, delete_discussion to remove one, list_announcements to see existing announcements, and post_discussion_entry to reply instead of editing the topic itself. Requires instructor/TA permission to manage discussions in the course.

Input Schema

NameRequiredDescriptionDefault
titleNoNew title for the discussion topic
messageNoNew body text (supports HTML)
topic_idYesThe Canvas discussion topic ID
course_idYesThe Canvas course ID
publishedNoPublish or unpublish the topic
delayed_post_atNoISO 8601 datetime to schedule the topic for future posting
is_announcementNoWhen true, requests marking the topic as an announcement. Canvas silently downgrades this to a plain discussion topic (no error) if the caller lacks announcement permission in the course — check the response's own `is_announcement` field rather than assuming the request was honored.
require_initial_postNoRequire students to post before seeing replies

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.15
    • 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 / topic_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / topic_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. Changed1 schema field changedv1.18.8
    • changedInput schema / properties / delayed_post_at / pattern
      Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  4. Changed1 schema field changedv1.18.4
    • changedInput schema / properties / is_announcement / description
      Previous value: -"When true, marks the topic as an announcement"New value: +"When true, requests marking the topic as an announcement. Canvas silently downgrades this to a plain discussion topic (no error) if the caller lacks announcement permission in the course — check the response's own `is_announcement` field rather than assuming the request was honored."
  5. Changed2 schema fields changedv1.18.3
    • addedInput schema / properties / delayed_post_at
      Added value: +{
+  "description": "ISO 8601 datetime to schedule the topic for future posting",
+  "format": "date-time",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$",
+  "type": "string"
+}
    • addedInput schema / properties / is_announcement
      Added value: +{
+  "description": "When true, marks the topic as an announcement",
+  "type": "boolean"
+}
  6. First observedv1.18.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses PATCH-style semantics (only passed fields change), a silent-failure mode where Canvas returns HTTP 200 but ignores is_announcement without permission, the tool's decision to throw instead of reporting false success, that the thrown error names the topic ID, and the required instructor/TA role. That is exactly the non-obvious behavior an agent needs before mutating a topic.

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-loads purpose and partial-update semantics, then scope limits, then the silent-failure caveat, then alternatives — a sensible ordering. It is dense and the first sentence carries a long field list plus a return-value clause, but every sentence conveys distinct, actionable information and nothing 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 an 8-parameter mutation tool with no output schema, the description covers the gaps: it says what is returned, warns that the response's own is_announcement field must be verified rather than trusting the request, and states the permission prerequisite. Nothing an agent needs to invoke this safely is missing.

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 coverage is 100%, so baseline is 3, and the description adds genuine meaning on top: the partial-update contract ('only the fields you pass are changed, the rest keep their current value') is not inferable from the schema's optional properties. The is_announcement downgrade detail is valuable but largely duplicated by that parameter's own schema description, which caps this at 4 rather than 5.

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 ('Update an existing discussion topic in a course') and enumerates the mutable fields (title, message, published state, require_initial_post, delayed_post_at, is_announcement). It also declares its return value ('return the updated topic'), so the agent knows exactly what the call does without opening the schema.

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?

Explicitly routes away from four siblings: create_discussion for new topics, delete_discussion for removal, list_announcements for viewing announcements, and post_discussion_entry for replying rather than editing. It also states a hard boundary — course-scoped only, no group-discussion update, with list_group_discussions/get_group_discussion named as read-only fallbacks.

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