canvas_list_coursesLists your active Canvas courses and your role in each, returning course IDs needed by other tools; optionally include completed courses.
List your Canvas courses (active by default) with your role in each. Returns course ids needed by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| include_completed | No | Also include completed/past courses |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the non-obvious behavioral detail that completed courses are excluded unless requested and that role information comes back per course — context an agent would otherwise have to discover by trial. Pagination and rate-limit behavior remain undisclosed.
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?
Two short sentences with zero filler; the default-scope fact and the downstream-use note are both front-loaded before any caller needs to decide.
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?
With no output schema, the description does the necessary work of naming the returned fields (role per course, course ids). For a single-param read tool whose annotations cover the safety profile, that is nearly sufficient; only pagination/result-size behavior is unaddressed.
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 coverage is 100% and the single parameter documents itself ('Also include completed/past courses'), so the schema carries the load. 'Active by default' reinforces what that flag toggles but adds no syntax or format detail 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?
States a specific verb and resource ('List your Canvas courses') plus the exact payload ('with your role in each'), which no sibling tool duplicates. It positions itself in the workflow by noting it returns course ids needed elsewhere, though it doesn't explicitly name the siblings that consume those ids.
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?
'Returns course ids needed by other tools' tells the agent this is the entry point for the rest of the course-scoped workflow, and 'active by default' flags that the default view is filtered. No explicit when-not case or named alternative is given, but nothing in the sibling set conflicts with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.