Lists Canvas LMS courses accessible to the current user, with pagination control; use canvas_read for enrollment or state filters.
List courses accessible to you. Use canvas_read for enrollment/state filters.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and liveness profile is covered by structured data. The description adds only the access scoping ('accessible to you'); it says nothing about pagination volume, how many pages it will traverse, or whether results are truncated.
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, no filler, with the core purpose front-loaded and the routing hint immediately after. Every clause carries information an agent needs.
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?
An output schema exists, so return-value detail is legitimately omitted, and annotations cover the safety profile. However, for a paginated listing tool with a max_pages control the agent has to guess about, the description is under-specified on result volume and page traversal behavior.
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 0%: the single parameter max_pages (default 1, max 20) has no description in the schema and is never mentioned in the tool description. The description therefore fails to compensate for the coverage gap, leaving the agent to infer that max_pages controls pagination depth and that the default returns only the first page of courses.
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 courses accessible to you') with a scope qualifier (accessible to you) that implies it is an enrollment-scoped listing. It names one sibling, canvas_read, as the alternative for filtering, so an agent can distinguish it from the filter-oriented path, though it does not differentiate itself from canvas_discover or canvas_outline.
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?
Explicitly routes the agent: for enrollment/state filtering, use canvas_read instead. That is a clear alternative with a condition that selects it. It stops short of stating exclusions in the other direction (e.g. when canvas_discover or canvas_outline is preferred), so it is not a full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.