Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

List Outcome Groups

list_outcome_groups
Read-onlyIdempotent

List how a course’s learning outcomes are organized into groups and subgroups so you can review their structure; use list_outcomes for the outcomes themselves.

Instructions

List how a course's learning outcomes are organized into groups and subgroups. Read-only. Use list_outcomes for the outcomes themselves.

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

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the sentence "Read-only" mostly restates structured data. The description does add a useful structural hint that the result is a hierarchy of groups and subgroups, but says nothing about whether empty groups appear, depth of nesting, or pagination.

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 short sentences, front-loaded with the purpose, followed by the safety note and the disambiguation. No filler or repetition beyond the arguably redundant "Read-only" clause.

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?

A single-parameter read tool whose schema is fully documented and whose safety profile is carried by annotations; the description supplies the one thing not in structured data, namely how this differs from list_outcomes. No output schema exists, so return-shape detail is not required.

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, and the schema documents it fully at 100% coverage, including how to obtain the Canvas course ID from list_courses. The description adds no additional meaning about scope, filtering, or defaults, 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?

States a specific verb and resource — how a course's learning outcomes are organized into groups and subgroups — and distinguishes itself from the closely named sibling list_outcomes in the same breath. An agent can tell the two apart 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 Guidelines4/5

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

Explicitly routes the agent to list_outcomes "for the outcomes themselves," giving a clear alternative for the adjacent use case. It does not spell out exclusions (e.g. when neither tool applies) or note that a course_id must first be obtained via list_courses, though the schema covers that.

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