Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Peer Reviews

list_peer_reviews
Read-only

List all peer reviews on a Canvas assignment, including reviewer and reviewee IDs; pass submission_id to scope results to a single submission.

Instructions

List every peer review assigned on an assignment, across every submission, returning each review's id, assessor_id (the reviewer), user_id (the reviewee whose submission is being reviewed), asset_id, and workflow_state ('assigned' or 'completed'). Fetches every page (100 per request) and fails with a 'Results are incomplete' error instead of silently truncating. Pass submission_id to scope the results to the reviews assigned to that one submission instead of the whole assignment — the same result get_submission_peer_reviews returns, kept here as a shortcut. Omit it to see every review across the assignment. Use create_peer_review to assign a new reviewer, and delete_peer_review to remove one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "course_id": "<course_id>",
      "assignment_id": "<assignment_id>"
    },
    "name": "list_peer_reviews"
  }
}

Input Schema

NameRequiredDescriptionDefault
course_idYesThe Canvas course ID
assignment_idYesThe Canvas assignment ID
submission_idNoOptional Canvas submission ID. When provided, scopes results to the peer reviews assigned to this submission instead of every peer review on the assignment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.20
    • addedInput schema / properties / submission_id
      Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    {
+      "pattern": "^[1-9][0-9]{0,18}$",
+      "type": "string"
+    }
+  ],
+  "description": "Optional Canvas submission ID. When provided, scopes results to the peer reviews assigned to this submission instead of every peer review on the assignment."
+}
  2. Changed4 schema fields changedv1.18.15
    • addedInput schema / properties / assignment_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / assignment_id / 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"
  3. 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"
  4. First observedv1.18.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover the read-only safety profile, so the description's real contribution is the pagination behavior (100 per request, fetches all pages) and the deliberate 'Results are incomplete' failure instead of silent truncation — genuinely useful operational context. It stops short of stating permission/auth requirements or whether openWorldHint implies cross-course visibility.

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?

Front-loads the scope, then pagination behavior, then the optional-parameter branch, then alternatives. Every sentence carries distinct information, and the field enumeration earns its place because no output schema exists.

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 supplies the return shape (ids, workflow_state values), pagination and failure semantics, and the scoping branch. Nothing an agent needs to call this correctly is 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 100%, so the baseline would be 3; the description goes beyond it by explaining the semantics of submission_id — that it narrows results from assignment-wide to one submission and is equivalent to another tool's output. course_id and assignment_id are left to the schema, which is adequate given their clarity.

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 ('List every peer review assigned on an assignment, across every submission') and enumerates the returned fields. It explicitly distinguishes itself from the sibling shortcut get_submission_peer_reviews and from create/delete_peer_review, so an agent knows exactly what this retrieves.

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 explicit when-to-use guidance: pass submission_id to scope to one submission (same result as get_submission_peer_reviews), omit it to see the whole assignment, and names create_peer_review / delete_peer_review as the mutation alternatives. Both branches of the optional parameter are covered.

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