Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Assignments

list_assignments
Read-only

List all assignments in a course. Use fields="slim" when enumerating assignments for selection; switch to "full" once you've identified the target. slim returns id, name, due_at, points_possible, published, and course_id only.

Instructions

List all assignments in a course. Use fields="slim" when enumerating assignments for selection; switch to "full" once you've identified the target. slim returns id, name, due_at, points_possible, published, and course_id only. "full" (default) includes all Canvas fields plus include extras (submission, all_dates, overrides, score_statistics, etc.). Use bucket to filter by past/upcoming/overdue/etc. Other filters: search_term, assignment_ids, order_by.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bucketNoOnly include assignments in the given bucket
fieldsNoProjection mode: "slim" returns id/name/due_at/points_possible/published/course_id only; "full" (default) returns all fields
includeNoExtra fields to include on each assignment (Canvas include[] param); ignored when fields="slim"
order_byNoField to sort the result by
course_idYesThe Canvas course ID
post_to_sisNoFilter to assignments that are/are not posted to SIS
search_termNoPartial name substring to filter assignments by
assignment_idsNoRestrict to the given list of assignment IDs
override_assignment_datesNoApply assignment overrides to due/unlock/lock dates (default Canvas behavior: true)
needs_grading_count_by_sectionNoBreak needs_grading_count down by section

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.15
    • addedInput schema / properties / assignment_ids / items / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / assignment_ids / items / type
      Removed value: -"number"
    • 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"
  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. Changed2 schema fields changedv1.18.2
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Projection mode: \"slim\" returns id/name/due_at/points_possible/published/course_id only; \"full\" (default) returns all fields",
+  "enum": [
+    "slim",
+    "full"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / include / description
      Previous value: -"Extra fields to include on each assignment (Canvas include[] param)"New value: +"Extra fields to include on each assignment (Canvas include[] param); ignored when fields=\"slim\""
  4. First observedv1.18.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing the shape of the response under each projection (slim returns id/name/due_at/points_possible/published/course_id; full adds Canvas fields plus include extras), effectively substituting for the absent output schema. Pagination and rate-limit behavior are not mentioned.

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?

Dense and front-loaded: capability first, then projection strategy, then filtering. Some sentences duplicate enum detail already in the schema (the slim field list, the include names), which costs a little against a strict conciseness standard.

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 10-parameter list tool with no output schema, the description covers the highest-value decisions: projection mode and filtering strategy, plus the return-shape difference. It stops short of mentioning pagination or result-limit behavior, which is the main remaining gap for a list endpoint on an open-world API.

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 description coverage is 100%, so the baseline is 3; the description earns a bump by explaining the strategic relationship between `fields` and `include` (extras are only meaningful in full mode) rather than just restating enum values. It does, however, list only search_term/assignment_ids/order_by as "other filters" while silently omitting post_to_sis, override_assignment_dates and needs_grading_count_by_section.

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?

Opens with a specific verb+resource and scope ("List all assignments in a course"), which is unambiguous against the singular get_assignment/create_assignment/update_assignment siblings. It never names an alternative tool, so an agent must infer the boundary by naming convention alone.

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?

Gives real workflow guidance: use fields="slim" while enumerating for selection, switch to "full" once the target is identified, and use `bucket` for past/upcoming/overdue filtering. It does not distinguish this tool from nearby list tools such as list_assignment_overrides or list_assignment_groups, so no explicit alternatives are offered.

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