Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Student Quiz Accommodations

list_student_quiz_accommodations
Read-only

List the current quiz accommodation (extra time and/or extra attempts) for a specific student across all Classic Quizzes in a course. Useful for auditing before or after calling set_student_quiz_accommodation.

Instructions

List the current quiz accommodation (extra time and/or extra attempts) for a specific student across all Classic Quizzes in a course. Useful for auditing before or after calling set_student_quiz_accommodation. New Quizzes (quiz_type quizzes.next) are excluded. Reads extra_time / extra_attempts from each quiz's submission records (Canvas exposes no read endpoint for quiz extensions directly) — one Canvas API call per Classic Quiz, so it may be slow for courses with many quizzes. Errors from any quiz's read propagate immediately (no per-quiz error catching). Provide user_id as the real Canvas user ID. If CANVAS_PSEUDONYMIZE_STUDENTS is enabled, call resolve_pseudonym first.

Input Schema

NameRequiredDescriptionDefault
user_idYesReal Canvas user ID of the student
course_idYesCanvas course ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 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 / exclusiveMinimum
      Removed value: -0
    • removedInput schema / properties / course_id / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / course_id / type
      Removed value: -"integer"
    • 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 / exclusiveMinimum
      Removed value: -0
    • removedInput schema / properties / user_id / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / user_id / type
      Removed value: -"integer"
  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. Addedv1.18.3

TDQS

A4.5/5.0
Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations: it discloses that reads are derived from submission records because Canvas exposes no extensions endpoint, that cost scales one API call per Classic Quiz (may be slow), and that errors from any quiz propagate immediately with no per-quiz catching. These are exactly the behavioral traits an agent needs before invoking.

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?

A single dense paragraph, front-loaded with purpose then behavior, performance, errors, and prerequisites; every sentence carries information. It could be easier to scan as bullets, but nothing is wasted.

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?

With no output schema, the description still conveys what is returned (extra_time / extra_attempts per quiz) and covers cost, failure mode, and ID handling. It could say slightly more about the returned shape or ordering across quizzes, but it is otherwise complete for a read-only listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description's user_id guidance ('real Canvas user ID') largely restates the schema's own description. The pseudonymization prerequisite adds genuine context, but the parameters themselves gain little beyond the schema, so baseline 3 is appropriate.

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 (list), resource (quiz accommodations), and scope (extra time/attempts for one student across all Classic Quizzes in a course). It explicitly excludes New Quizzes, which cleanly separates it from the sibling list_student_new_quiz_accommodations and from set_student_quiz_accommodation.

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?

Gives an explicit use case ('auditing before or after calling set_student_quiz_accommodation'), an explicit exclusion (New Quizzes quizzes.next), and a prerequisite ('call resolve_pseudonym first' when pseudonymization is enabled). An agent has everything needed to decide whether to call this tool.

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