Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Enroll User

enroll_user
Destructive

Enroll a user in a Canvas course with a chosen role, optional section, and enrollment state; returns the created enrollment object including its ID and state.

Instructions

Enroll a user in a course with a given role (StudentEnrollment, TeacherEnrollment, TaEnrollment, ObserverEnrollment, or DesignerEnrollment) and return the created enrollment object, including its id and enrollment_state. Use list_course_enrollments with a user_id filter to check a user's existing enrollments before enrolling them again, and remove_enrollment to conclude, deactivate, or permanently delete this enrollment afterward — enroll_user itself has no way to undo what it creates. Omitting enrollment_state leaves it at Canvas's documented default of "invited", so the user must accept a course invitation before the enrollment becomes active; pass enrollment_state: "active" to skip that step. Omitting course_section_id leaves Canvas to place the enrollment in the course's default section — read list_sections for the ID of a specific one. limit_privileges_to_course_section confines the user to that section: for teachers and TAs that includes grading privileges, and a section-limited student sees no user outside their own sections, teachers included. Both are left entirely unset when omitted, so the request is unchanged from a call that does not pass them. Requires permission to manage enrollments in the course; Canvas rejects the call otherwise.

Input Schema

NameRequiredDescriptionDefault
typeYesThe enrollment type
user_idYesThe Canvas user ID to enroll
course_idYesThe Canvas course ID
enrollment_stateNoInitial enrollment state (defaults to invited)
course_section_idNoThe section to enroll the user into (from `list_sections`); omitted = the course's default section
limit_privileges_to_course_sectionNoRestrict the user to seeing and interacting with users in course_section_id only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.18.20
    • addedInput schema / properties / course_section_id
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    {
+      "pattern": "^[1-9][0-9]{0,18}$",
+      "type": "string"
+    }
+  ],
+  "description": "The section to enroll the user into (from `list_sections`); omitted = the course's default section"
+}
    • addedInput schema / properties / limit_privileges_to_course_section
      Added value: +{
+  "description": "Restrict the user to seeing and interacting with users in course_section_id only",
+  "type": "boolean"
+}
  2. 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 / 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"
  3. 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"
  4. First observedv1.18.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag openWorldHint and destructiveHint; the description earns credit by spelling out what the destructiveness means ('no way to undo what it creates'), the invited-by-default state and its acceptance requirement, section defaulting, privilege confinement effects for teachers/TAs/students, and the permission requirement with failure behavior ('Canvas rejects the call otherwise').

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?

Effect and return value are front-loaded, and each clause carries distinct information (undo path, state default, section default, privilege scope, permissions). It is a single dense block of run-on clauses rather than cleanly segmented sentences, costing some readability.

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 6-parameter mutation tool with no output schema, the description covers the return payload, defaults for every optional parameter, permission prerequisites, and the reversal path. 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.

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; the description adds real value beyond it — the practical consequence of the 'invited' default and how to bypass it with 'active', the pointer to list_sections for course_section_id, and the grading/visibility implications of limit_privileges_to_course_section. It slightly restates the schema's default notes, which keeps it from a 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 ('Enroll a user in a course'), enumerates the enrollment role values, and names the return payload (id, enrollment_state). It also implicitly separates itself from list_course_enrollments and remove_enrollment, so an agent can place it precisely.

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?

Explicit pre-check guidance ('Use list_course_enrollments with a user_id filter to check a user's existing enrollments before enrolling them again') and an explicit exit path ('remove_enrollment to conclude, deactivate, or permanently delete'). No inference required.

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