Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

Get Rubric

get_rubric
Read-onlyIdempotent

Retrieve a full rubric with every criterion, rating level, and point value. Read it before starting work to know exactly how the assignment will be scored.

Instructions

Get a full rubric: every criterion, rating level and point value. Read-only. Read it before starting work to know how it will be scored; get_rubric_assessment shows how your submission was scored.

Input Schema

NameRequiredDescriptionDefault
course_idYesCanvas course ID, a numeric string such as "12345". Get it from list_courses.
rubric_idYesRubric ID (numeric string). Get it from list_rubrics or get_assignment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.3
    • changedInput schema / properties / course_id / description
      Previous value: -"Canvas course ID"New value: +"Canvas course ID, a numeric string such as \"12345\". Get it from list_courses."
    • changedInput schema / properties / rubric_id / description
      Previous value: -"Canvas ID (numeric string)"New value: +"Rubric ID (numeric string). Get it from list_rubrics or get_assignment."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the sentence 'Read-only' adds nothing structured data doesn't already say. The description does add the payload shape and a scope boundary against the sibling, but says nothing about auth requirements, error cases, or whether rubrics can be missing/unpublished.

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?

Two compact sentences, front-loaded with the resource scope before the usage routing. No restatement of the title and nothing extraneous.

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 usefully enumerates what comes back (criteria, rating levels, point values) and where to get the scoring counterpart. Only gap is any failure/lookup behavior for a missing rubric_id, which is minor for a two-parameter read 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 description coverage is 100% and both required parameters already document their own format and provenance ('Get it from list_rubrics or get_assignment'). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 plus the exact payload scope: 'every criterion, rating level and point value'. It also explicitly contrasts itself with get_rubric_assessment, so an agent can distinguish the two rubric tools without opening either schema.

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 a concrete when-to-use ('read it before starting work to know how it will be scored') and a named alternative with its own condition ('get_rubric_assessment shows how your submission was scored'). The selection logic between the sibling pair is fully explicit.

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