Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Quiz Question Responses

get_quiz_question_responses
Read-only

Get student responses for one or all Classic Quiz questions, organized by question, to grade essay, short-answer, and file-upload answers consistently.

Instructions

Review every student's answer to one or all questions in a Classic Quiz, pivoted by question instead of by student — for grading essay/short-answer/file-upload questions consistently across a class instead of paging through SpeedGrader one student at a time. Classic Quizzes only (quiz_type: assignment, practice_quiz, graded_survey, survey) — New Quizzes exposes responses through a different API. Omit question_id to get every question; provide it to scope to one. Each question reports needs_manual_grading (true for essay and file-upload questions) and points_possible. Questions drawn from a question bank are included: Canvas stores each draw as a generated question that the quiz's question list omits, so they are resolved from the students' own attempts, listed after the quiz's fixed questions, and report position: null. Scans one Canvas API call per completed or pending-review submission, plus one per attempt needed to resolve such questions. A failed per-submission fetch is recorded in submissions_failed, and a response whose question cannot be resolved is counted in unmatched_response_count and unmatched_question_ids, rather than aborting the whole call. When CANVAS_PSEUDONYMIZE_STUDENTS is enabled, student names are replaced with stable pseudonyms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quiz_idYesThe Canvas quiz ID (Classic Quizzes only)
course_idYesThe Canvas course ID
question_idNoScope the result to a single question ID (from list_quiz_questions, or a bank-drawn question_id returned by this tool). Omit to return every question with every student's response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.14
    • changedInput schema / properties / question_id / description
      Previous value: -"Scope the result to a single question ID (from list_quiz_questions). Omit to return every question with every student's response."New value: +"Scope the result to a single question ID (from list_quiz_questions, or a bank-drawn question_id returned by this tool). Omit to return every question with every student's response."
  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.7/5.0
Behavior5/5

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

The annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: per-submission API call scanning, handling of failed fetches via submissions_failed, unmatched_response_count/unmatched_question_ids, question-bank draw resolution, and pseudonymization behavior. This goes well beyond the structured annotations.

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 description is long but every sentence carries operational value: purpose, scope, exclusions, question-bank behavior, API cost, error handling, and anonymization. It is front-loaded with the main use case and avoids 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?

With no output schema, the description compensates by describing the key returned fields (needs_manual_grading, points_possible), failure counters, and per-question scoping behavior. It also addresses edge cases like bank-drawn questions and pseudonymization, making it complete for an agent to decide to call and interpret results.

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 the baseline is 3. The description adds meaning beyond the schema by explaining the omission/provision semantics of question_id, clarifying that bank-drawn question_ids can be passed back, and noting Classic Quiz type constraints referenced by quiz_id.

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: reviewing every student's answer to one or all questions in a Classic Quiz, pivoted by question rather than by student. It clearly distinguishes itself from per-student workflows and from New Quizzes APIs, so an agent can identify its niche among quiz-related tools.

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 clear context: use for grading essay/short-answer/file-upload questions consistently across a class, Classic Quizzes only, and explains how to scope via question_id. It does not explicitly name sibling tool alternatives, but it does say New Quizzes uses a different API, providing a meaningful exclusion.

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