Skip to main content
Glama
bruchris

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Audit Course Accessibility

audit_course_accessibility
Read-only

Scan a course's content (pages, assignments, syllabus, announcements, and optionally quizzes) for structurally-detectable WCAG 2.1 accessibility problems: images missing alt text or with low-quality (filename/generic) alt text…

Instructions

Scan a course's content (pages, assignments, syllabus, announcements, and optionally quizzes) for structurally-detectable WCAG 2.1 accessibility problems: images missing alt text or with low-quality (filename/generic) alt text, non-descriptive link text ("click here"), adjacent duplicate links, skipped/empty/overlong headings, and tables missing headers, header scope, or captions. Each finding carries a WCAG success criterion and a severity (error = unambiguous failure, advisory = needs human review). Structural checks only — no color-contrast checking (requires rendered theme CSS this tool cannot see) and no list-misuse detection in this version. Pass "quizzes" in include to also scan Classic quiz descriptions/questions and New Quiz item stems (opt-in, off by default). Complements — does not replace — Canvas's own in-app Accessibility Checker (course navigation → Accessibility → Scan Course), which covers the same WCAG areas plus rendered color contrast and offers in-UI remediation. Requires instructor permissions in the course.

Input Schema

NameRequiredDescriptionDefault
includeNoContent sources to scan. Omit to scan the default four: pages, assignments, syllabus, announcements. `quizzes` is opt-in — pass it explicitly to also scan Classic quiz descriptions/questions and New Quiz item stems.
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.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantial beyond-schema context: the exact severity taxonomy (error vs advisory), explicit limitations (no color-contrast checking, no list-misuse detection), the opt-in quizzes behavior, and required permissions. This is rich disclosure.

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 dense and long, but it is front-loaded with purpose and each clause earns its place by specifying checks, limitations, or permissions. Slight verbosity for a two-parameter tool keeps it below a 5.

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?

Despite no output schema, the description explains that findings carry a WCAG success criterion and severity level, and it scopes exclusions and permissions. An agent has everything needed to invoke it correctly and interpret results.

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 reinforces meaningfully that omitting `include` scans the default four sources and that `quizzes` must be passed explicitly for opt-in scanning, adding behavioral nuance beyond the raw schema text.

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 (scan/audit) and resource (course content for WCAG 2.1 structural accessibility problems), and enumerates exactly what it detects. An agent can distinguish it from audit_course_links, check_course_setup, and Canvas's in-app Accessibility Checker without inspecting another schema.

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?

Gives clear context: requires instructor permissions, complements rather than replaces Canvas's in-app checker, and explains the quizzes opt-in. It does not explicitly route against sibling audit tools, but the usage conditions and exclusions are well stated.

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