Retrieve your Canvas to-do list to see assignments still to submit and, for teachers, items awaiting grading.
Your Canvas to-do list as on the dashboard: assignments still to submit (and, for teachers, to grade).
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | true: Canvas's unmodified JSON (UTC times, HTML). | |
| page | No | Page to fetch: a number, or the next_page value returned by the previous call. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds useful scope information (only outstanding submissions, teacher grading items), but says nothing about pagination behavior, ordering, or why a 'raw' mode exists beyond what the schema states.
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?
A single sentence with the resource stated first and the scope qualifier immediately after. Every clause earns its place, and nothing is padded.
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?
For a two-parameter read-only list tool with full schema coverage and complete annotations, the description says enough to call it correctly. The remaining minor gap is that it never mentions that results are paginated or what ordering to expect, which matters for a to-do list an agent may need to page through.
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 both parameters carry their own descriptions (raw = unmodified JSON with UTC times and HTML; page = number or bookmark token). The description adds no meaning beyond the schema, so the baseline of 3 applies.
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?
Names a specific resource (the Canvas to-do list) and pins down its contents: assignments still to submit, plus ungraded items for teachers. An agent can distinguish this from canvas_assignments or canvas_upcoming_events by the 'still to submit / to grade' scoping and the dashboard framing, though no sibling is named explicitly.
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?
Usage is implied by the 'as on the dashboard' framing, which signals a personal action list rather than a course-wide listing. However, it never states when to prefer this over canvas_assignments or canvas_upcoming_events, nor any prerequisites such as needing an authenticated user context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.