Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Check Course Setup

check_course_setup
Read-only

Run a factual course-readiness report that surfaces common configuration problems — assignments missing due dates, unpublished items students will not see, gradebook weighting gaps, graded assignments with no points, and published…

Instructions

Run a factual course-readiness report that surfaces common configuration problems — assignments missing due dates, unpublished items students will not see, gradebook weighting gaps, graded assignments with no points, and published assignments still accepting submissions after their due date. Returns findings grouped by check with a plain-language detail per item. This is a config-health report only; it does not inspect student submissions or performance (see list_students_needing_attention / get_missing_submissions for those). Requires instructor permissions in the course.

Input Schema

NameRequiredDescriptionDefault
checksNoSubset of checks to run. Omit to run all five checks. Valid values: missing_due_dates, unpublished_items, assignment_group_weights, ungraded_setup, submissions_open_past_due.
course_idYesCanvas course ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.15
    • 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 / exclusiveMinimum
      Removed value: -0
    • removedInput schema / properties / course_id / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / course_id / type
      Removed value: -"integer"
  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
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that: the return shape ("findings grouped by check with a plain-language detail per item") and an explicit permission requirement, both of which the annotations do not convey.

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?

Three sentences, front-loaded with the core action, then scope boundaries, alternatives, and prerequisites in descending order of importance. No filler or repetition; every clause carries routing or behavioral 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?

With no output schema, the description takes on the burden of describing the return shape and does so. Combined with permission requirements and the explicit exclusion of submission/performance analysis, an agent has everything needed to call this correctly and interpret the result.

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 goes further by spelling out in plain language what each check identifier actually detects (e.g. "published assignments still accepting submissions after their due date"), which lets the agent choose a `checks` subset without guessing at enum meanings. It does not, however, restate that omitting `checks` runs all five.

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+resource ("Run a factual course-readiness report") and then enumerates the concrete problem classes it detects, so the agent knows exactly what this tool produces. It explicitly distinguishes itself from list_students_needing_attention and get_missing_submissions, which is critical in a sibling set this large.

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 an explicit when-not boundary ("config-health report only; it does not inspect student submissions or performance") and names the two alternative tools for that adjacent use case. It also states the prerequisite ("Requires instructor permissions in the course"), so the agent can route and gate correctly.

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