Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Outcome

get_outcome
Read-only

Get the full details for one learning outcome by outcome_id, including its rating criteria, mastery_points, and calculation_method.

Instructions

Get the full details for one learning outcome by outcome_id, including its rating criteria, mastery_points, and calculation_method. The outcome_id comes from list_outcome_group_outcomes, list_outcome_group_links, or get_outcome_results' / get_outcome_rollups' linked.outcomes; get_outcome_alignments lists all alignments in the course (not scoped to one outcome) — cross-reference via get_outcome_results instead to tie an alignment to this outcome_id.

Input Schema

NameRequiredDescriptionDefault
outcome_idYesThe Canvas outcome ID.
add_defaultsNoInclude default mastery colors and levels when Canvas supports it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.18.15
    • addedInput schema / properties / outcome_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / outcome_id / type
      Removed value: -"number"
  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. First observedv1.18.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds what the call actually yields (details plus rating criteria, mastery_points, calculation_method) and discloses the lineage constraint on get_outcome_alignments, which is meaningful beyond the annotations. It does not discuss error behavior for an invalid/stale ID.

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?

Two sentences, front-loaded with the core action and payload. The second sentence is dense with tool names but each clause carries routing information an agent needs; nothing is padding.

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 correctly names the key returned fields so the agent knows what it gets back, and it supplies the ID-provenance chain needed to call the tool successfully. Only minor gaps remain (behavior on invalid IDs, the add_defaults flag).

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 baseline is 3, but the description adds provenance semantics the schema lacks — naming the three tools that produce a compatible outcome_id. The optional add_defaults parameter is never mentioned, keeping it just short of a 5.

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 ('Get the full details for one learning outcome by outcome_id') and enumerates the returned content (rating criteria, mastery_points, calculation_method), which cleanly separates it from siblings like list_outcome_group_outcomes and get_outcome_alignments.

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 tells the agent where a valid outcome_id comes from (three named sibling tools) and warns that get_outcome_alignments is not scoped to a single outcome, redirecting to get_outcome_results. No explicit 'do not use this when...' exclusion, but the routing guidance is strong.

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