Skip to main content
Glama

Create Discussion Topic

create_discussion_topic

Create and publish a discussion topic in a Canvas course so students can view it immediately or on a scheduled delayed post date. Use it to start course conversations with a title and message.

Instructions

Create and publish a discussion topic in a course.

The topic is always created published (there is no draft option here), so students can see it on creation unless delayed_post_at schedules it for later. Unpublishing afterwards with update_discussion_topic does not undo that initial visibility; if the topic must not be seen yet, use delayed_post_at or confirm with the user first. If create_announcement failed, do not post that content here instead: report the failure, because re-posting it publishes the message somewhere the user did not choose.

Input Schema

NameRequiredDescriptionDefault
titleYesDiscussion topic title
pinnedNoPin this discussion topic (default: False)
lock_atNoISO 8601 datetime to auto-lock the discussion
messageYesDiscussion topic body content
delayed_post_atNoISO 8601 datetime to schedule posting
course_identifierYesCourse code or Canvas ID
require_initial_postNoStudents must post before seeing others (default: False)

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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
  2. Changed19 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 / delayed_post_at / description
      Added value: +"ISO 8601 datetime to schedule posting"
    • removedInput schema / properties / delayed_post_at / title
      Removed value: -"Delayed Post At"
    • addedInput schema / properties / lock_at / description
      Added value: +"ISO 8601 datetime to auto-lock the discussion"
    • removedInput schema / properties / lock_at / title
      Removed value: -"Lock At"
    • addedInput schema / properties / message / description
      Added value: +"Discussion topic body content"
    • removedInput schema / properties / message / title
      Removed value: -"Message"
    • addedInput schema / properties / pinned / description
      Added value: +"Pin this discussion topic (default: False)"
    • removedInput schema / properties / pinned / title
      Removed value: -"Pinned"
    • addedInput schema / properties / require_initial_post / description
      Added value: +"Students must post before seeing others (default: False)"
    • removedInput schema / properties / require_initial_post / title
      Removed value: -"Require Initial Post"
    • addedInput schema / properties / title / description
      Added value: +"Discussion topic title"
    • removedInput schema / properties / title / title
      Removed value: -"Title"
    • removedInput schema / title
      Removed value: -"create_discussion_topicArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"create_discussion_topicOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  3. Changed1 schema field changedv1.0.0
    • addedInput schema / title
      Added value: +"create_discussion_topicArguments"
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations only state idempotentHint=false and destructiveHint=false, while the description adds critical behavioral context: the topic is always published on creation, students may see it immediately, and later unpublishing does not undo that initial visibility. It also warns against reposting failed announcement content, which is meaningful safety guidance beyond the 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?

The key behavior is front-loaded in the first sentence, and the remaining sentences focus on non-obvious publishing consequences and misuse prevention. There is no filler, and the caution about failed announcements earns its place as safety guidance.

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 mutation tool with sparse annotations and no output schema, the description covers the most important side effect: immediate publication and its visibility implications. It could mention authentication/permission requirements or return behavior, but the core invocation risks are well addressed.

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 all seven parameters are already documented. The description adds useful meaning for delayed_post_at by explaining that it schedules later visibility, which is more than the schema's plain 'schedule posting' wording, though it does not add analogous semantic detail for the other optional parameters.

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: 'Create and publish a discussion topic in a course.' It also differentiates from update_discussion_topic and create_announcement by explaining that unpublishing does not undo initial visibility and that failed announcement content should not be reposted here.

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 usage conditions and exclusions: there is no draft option, delayed_post_at should be used when the topic must not be visible yet, and failed create_announcement content should not be posted here. It does not fully spell out the general choice between discussion topics and announcements, but the context is strong.

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