Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Explain Grading Policy

explain_grading_policy
Read-only

Explain a Canvas course's grading policy: missing/late submission rules, assignment group weights, and letter-grade scheme, plus a shareable summary.

Instructions

Explains the grading automation rules configured for a Canvas course:

  • Missing-submission policy: whether blank/unsubmitted work is automatically scored 0 (or another deduction), or left unpenalised.

  • Late-submission policy: whether Canvas applies a per-day or per-hour percentage deduction to late submissions, and whether there is a floor below which the grade cannot fall.

  • Assignment-group weighting: whether the course uses weighted groups, and the weight of each group.

  • Grading scheme: whether a letter-grade scheme (A/B/C/F mapping) is applied to the final score.

Also returns a plain-language summary paragraph you can share with students or instructors.

Note: the late/missing policy section requires instructor or admin permissions. Students receive the group-weighting and grading-scheme sections only, with a caveat noting what is unavailable. Use explain_grade to compute the actual weighted grade for a specific student.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
course_idYesCanvas course ID to explain the grading policy for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Addedv1.18.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false Tal. The description adds valuable behavioral detail: the exact policy sections returned, the permission-dependent output differences, and the plain-language summary format. Notably, it also reveals that parts of the policy may be hidden for students, which is important context.

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?

Information is front-loaded with the core purpose in the first sentence, followed by well-organized bullet points covering each policy area, and a clear permission-related caveat at the end. No filler or redundancy.

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?

Given there is no output schema, the description does a good job of specifying what the returned explanation covers (four policy areas plus a plain-language summary) and the permission-dependent content. It stops short of describing the exact output shape, but for this kind of explanatory read-only tool, the context is largely sufficient.

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% for the single course_id parameter; the schema fully documents it as a Canvas course ID. The description adds no parameter-level semantics beyond what is already in the schema, so the baseline of 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?

The description uses a specific verb ('explains') and names exactly what the tool covers: missing-submission policy, late-submission policy, assignment-group weighting, and grading scheme. This is clearly distinguishable from sibling tools like get_course or list_assignment_groups.

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?

Provides clear context on when the tool is appropriate and includes a permission caveat (students vs. instructors/admins receive different sections). It does not explicitly name an alternative tool, but the usage scenario is clear enough without one.

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