get_all_gradesFetch current and final grades for every active Canvas course in a single read-only call, including unposted grades where shown, to monitor academic progress.
Get your current and final grades for every active course in one call, including unposted grades where Canvas shows them. Read-only. Use get_course_grade_breakdown to see how one course's grade is calculated.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the description's 'Read-only' is largely redundant. What it genuinely adds is the coverage nuance about unposted grades only appearing 'where Canvas shows them,' warning that results may be incomplete. It does not describe the per-course result shape or ordering.
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?
Three short sentences, zero filler, with the core capability front-loaded and the disambiguation last. Every sentence carries distinct information.
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 zero-parameter, no-output-schema tool, the description covers scope, safety, the unposted-grade caveat, and the sibling alternative. A brief note on what each entry contains (course name plus current/final score) would close the last gap for an agent assembling a response.
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?
The tool takes zero parameters, so there are no argument semantics to explain; baseline 4 applies. The description correctly offers no parameter chatter, avoiding inventing filters that do not exist.
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 ('Get your current and final grades') plus the scope ('every active course in one call'), and adds a nuance ('including unposted grades where Canvas shows them') that no sibling covers. It is clearly distinguishable from the per-course breakdown sibling.
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: use this for the whole picture, use get_course_grade_breakdown 'to see how one course's grade is calculated.' The when-to-use-this vs alternative split is stated outright rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.