Canvas LMS MCP Server

Get Rubric Assessment

get_rubric_assessment

Read-only

Retrieve one student's Canvas submission with its rubric assessment by criterion ID, including ratings, comments, and points per criterion, without exposing grader identity.

Instructions

Get one student's submission for an assignment with the Canvas rubric_assessment attached, keyed by criterion_id (rating_id, comments, points per criterion) — this does not carry the assessor's name or any grader identity. This is the same full submission object (score, grade, workflow_state, submitted_at) that get_submission returns, requested here with include[]=rubric_assessment instead of get_submission's default submission_comments; use get_submission when you also need comments or the submitted text/URL. Use submit_rubric_assessment to post a rubric assessment for a student rather than read one back.

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>",
      "user_id": "<user_id>"
    },
    "name": "get_rubric_assessment"
  }
}

Input Schema

Name	Required	Description
`user_id`	Yes	The Canvas user ID
`course_id`	Yes	The Canvas course ID
`assignment_id`	Yes	The Canvas assignment ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.18.15Oct 14, 2026

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"
```

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 / type
```
Removed value: -"number"
```

Changed1 schema field changedv1.18.11Sep 10, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv1.18.0May 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantive behavioral context: the returned object is the full submission (score, grade, workflow_state, submitted_at), it uses include[]=rubric_assessment, and it does not carry the assessor's name or grader identity.

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 front-loaded with the core purpose and return shape, then covers exclusions and alternatives. It is dense but every sentence contributes useful routing or return-value information.

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?

For a simple read operation with no output schema, the description supplies enough return-value detail and sibling routing to call it correctly. Annotations cover the safety profile, and the description fills in the remaining behavioral gaps.

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 description coverage is 100%, so all three required ID parameters are documented directly in the schema. The description implies user_id refers to the student whose submission is fetched, but it does not add syntax or selection guidance beyond that baseline.

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?

The description states a specific verb and resource: get one student's submission with the Canvas rubric_assessment attached. It names what is included per criterion (rating_id, comments, points) and explicitly distinguishes this from get_submission and submit_rubric_assessment.

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?

It gives explicit routing guidance: use get_submission when you also need comments or the submitted text/URL, and use submit_rubric_assessment to post rather than read. The when-to-use and when-not-to-use conditions are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server