list_outcome_groupsList outcome groups for any Canvas account or course. Provide context type and ID to fetch associated learning outcome groupings.
List all outcome groups for an account or course context.
| Name | Required | Description | Default |
|---|---|---|---|
| context_id | Yes | The Canvas account ID or course ID for the context. | |
| context_type | Yes | Whether to read outcome groups from an account or course context. |
Changes observed during successful MCP inspections.
v1.18.11Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v1.18.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature of the operation is covered. The description adds only the 'all outcome groups' scope and context restriction, while not disclosing whether nested subgroups are included, pagination behavior, or result ordering; however, the annotation lowers the burden here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that states the verb, resource, and scope with no filler or repeated annotation content. It is front-loaded and easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a straightforward two-parameter list call, and the read-only nature is covered by annotations. However, with no output schema and no clarification of whether 'all outcome groups' includes nested subgroups or how pagination works, an agent gets limited guidance on result shape and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters already have meaningful descriptions and an enum for context_type. The tool description adds no parameter-level detail beyond restating 'account or course context,' so it provides no incremental semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('List all outcome groups') and the resource scoping ('account or course context'), which makes the tool's basic purpose unmistakable. It does not explicitly contrast with closely related sibling tools like list_outcome_group_subgroups or get_outcome_group, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance, despite a large sibling set of outcome-related tools. The account/course scoping is present, but it is already expressed in the schema and no alternative tool is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.