Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Course Users

list_course_users
Read-only

Retrieve course rosters with filters for role, enrollment status, search term, or specific user IDs. Optionally include extra fields like email and enrollments.

Instructions

List users in a course with optional Canvas filters. Use include to request email, enrollments, avatar_url, bio, and other fields otherwise omitted from the default response. Use enrollment_type / enrollment_state to narrow by role or status, search_term to filter by name/login, user_ids to fetch a specific subset, and sort/order to control ordering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort field
orderNoSort order
includeNoExtra fields to include on each user (Canvas include[] param)
user_idsNoRestrict the result to the given user IDs
course_idYesThe Canvas course ID
search_termNoPartial name or full login/SIS ID to filter users by
enrollment_typeNoFilter by one or more enrollment types
enrollment_stateNoFilter by enrollment state (e.g. active, invited)

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Changed2 schema fields changedv1.18.8
    • removedInput schema / properties / user_ids / items / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]
    • addedInput schema / properties / user_ids / items / type
      Added value: +[
+  "number",
+  "string"
+]
  3. First observedv1.18.0

TDQS

B3.3/5.0
Behavior2/5

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

The annotations already declare readOnlyHint=true, so the agent knows this is safe and side-effect free. The description adds no behavioral context beyond the purpose: no mention of pagination, rate limiting, default result size, or any API-specific behavior. With annotations providing the core safety profile, the description should still disclose operational traits (e.g., 'paginated results') to be fully transparent; it does not.

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 description is composed of two sentences: the first a compact summary, the second a dense parameter walkthrough. There is no fluff, but the second sentence is a long list of parameter guidance, which is slightly less structured than separate bullets or explicitness per filter. Overall each sentence earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the eight parameters and no output schema, the description should explain what is returned (a list of users) and possibly the default return. It explains the purpose and the main filters but does not mention pagination, rate limits, or the shape of the response. For a straightforward list endpoint with a high-coverage schema, this is minimally sufficient but not fully complete.

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?

The schema provides descriptions for all 8 parameters, but the description goes further by explaining the purpose of the optional filters: e.g., 'include to request email... otherwise omitted from the default response' and 'enrollment_type / enrollment_state to narrow by role or status.' This clarifies use cases that the schema alone does not, adding real semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear action and object: 'List users in a course', which states the core purpose. It also lists the main filters, making the tool's scope easy to grasp. It does not explicitly name any sibling tools except implicitly through the filter list, so an agent must infer the distinction from context.

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

Usage Guidelines3/5

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

The description conveys when to use the tool implicitly – 'List users in a course' – and explains how to use several parameters. However, it never mentions alternative tools or provides exclusions (e.g., when to use list_course_enrollments, list_students, or search_users instead). The usage context is present but not contrasted with alternatives.

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