Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check Enrollment

check_enrollment
Read-only

Verify whether a specified campus login ID is enrolled in a Canvas course, returning a yes/no answer and minimal enrollment metadata without exposing roster details.

Instructions

Check whether a specific campus login ID is enrolled in a course.

Answers a roster-membership question about an externally-supplied person (NOT the caller). Returns only a yes/no plus minimal enrollment metadata — never the roster, names, or grades. Requires a Canvas token with roster-admin rights; without them the answer is INDETERMINATE, never "no".

To ask about YOURSELF, use get_my_enrollments instead — it needs no roster permission and cannot return an indeterminate answer.

Note that role defaults to "student". A NO answer is scoped to that role and will name any other role the person holds; pass role="any" when you just want to know whether they are in the course at all.

Input Schema

NameRequiredDescriptionDefault
roleNoEnrollment type that satisfies the check — "student" (default), "teacher", "ta", "observer", "designer", or "any".student
net_idYesThe person's campus login ID — NetID, uniqname, campus ID, or the full email-style Canvas login. Matched against Canvas `login_id` then `sis_user_id`; `jdoe` and `jdoe@example.edu` are treated as the same identifier. Not a display name.
active_onlyNoOnly count active enrollments (default True).
course_identifierYesCourse code, numeric ID, or SIS ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.15.0
    • changedInput schema / properties / net_id / description
      Previous value: -"The person's campus login ID — NetID, uniqname, campus ID, or\n  the full email-style Canvas login. Matched against Canvas\n  `login_id` then `sis_user_id`; `zqian` and `zqian@umich.edu`\n  are treated as the same identifier. NOT a display name."New value: +"The person's campus login ID — NetID, uniqname, campus ID, or\n  the full email-style Canvas login. Matched against Canvas\n  `login_id` then `sis_user_id`; `jdoe` and `jdoe@example.edu`\n  are treated as the same identifier. Not a display name."
  2. 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
  3. Addedv1.8.0

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint annotation: required roster-admin token rights, an INDETERMINATE result instead of a false negative, and strict limits on returned data. These are exactly the operational caveats an agent needs before calling a roster-membership checker.

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 purpose is front-loaded, followed by the permission/INDETERMINATE caveat, the return limitations, and the role default. Although longer than a minimal description, every paragraph addresses a distinct operational concern and 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?

Given a read-only tool with no output schema, the description is complete enough: it states the limited return shape, the permission dependency, the indeterminate outcome, and the self-versus-other routing. Nothing needed for correct invocation appears to be 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 already 100%, so the baseline is 3. The description still adds useful semantics for the role parameter, especially the default student scope, the fact that a NO may name another role, and the use of role="any"; it adds less beyond the schema for net_id and course_identifier.

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?

Starts with a precise verb and resource: checking whether a specific campus login ID is enrolled in a course. It explicitly contrasts the externally-supplied person with the caller, which distinguishes it from get_my_enrollments without requiring schema inspection.

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 self-enrollment questions to get_my_enrollments and explains the important role-scoping condition, including when to pass role="any". It also states the permission precondition and the INDETERMINATE outcome when roster-admin rights are missing.

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