Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

Get Course Settings

get_course_settings
Read-onlyIdempotent

Retrieve course-level settings such as final grade visibility, late policy display, and grading standard usage. Read-only; returns an error if a setting is hidden from students.

Instructions

Get course-level settings such as whether final grades are hidden, the late policy is shown, or a grading standard is used. Read-only. Some settings may be hidden from students, in which case Canvas returns an error.

Input Schema

NameRequiredDescriptionDefault
course_idYesCanvas course ID, a numeric string such as "12345". Get it from list_courses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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."
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: some settings may be hidden from students, and Canvas returns an error in that case, which prepares the agent for a failure mode.

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?

Three short sentences with the core purpose front-loaded and no filler. The example list is useful rather than redundant, though it could have been folded into a single clause.

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 gives enough of a shape of the return value (boolean-style course settings) and covers the error path. It stops short of saying what the response object looks like or whether all settings are always present.

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?

Only one parameter exists and the schema documents it fully at 100% coverage, including where to obtain the course_id. The description adds nothing about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get course-level settings) and gives concrete examples of the settings returned (final grades hidden, late policy shown, grading standard used). It does not distinguish itself from related siblings like get_my_settings, get_late_policy, or get_grading_standard, so an agent must infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when this is useful (inspecting course configuration) and notes read-only scope, but never says when to prefer it over per-setting siblings such as get_late_policy or get_grading_standard, nor any prerequisites like instructor permissions.

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