Retrieve active student enrollments with per-course current and final grades, plus grading period details for a student.
List active student enrollments with per-course grades (current_score, final_score, current_grade, final_grade, current grading period info).
| Name | Required | Description | Default |
|---|---|---|---|
| observeeId | No |
Changes observed during successful MCP inspections.
v2.0.0Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v1.2.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, and the description adds that only 'active' enrollments are returned and includes grading-period context. It does not mention pagination, data volume, permissions, or the significance of the observeeId parameter, but the annotation lowers the burden and the description is not misleading.
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 a single focused sentence that front-loads the core action and resource, then adds relevant output details in a parenthetical. There is no fluff, repetition, or unnecessary structure.
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?
Although the tool is simple, the description omits the role of observeeId and the scope of the enrollment listing. An agent could not confidently determine what to pass or whether the call returns enrollments for the current user or a specified observee. The output fields are listed, but invocation semantics are incomplete.
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 input schema only exposes observeeId with no description, and the description does not explain what observeeId means, whether it is required, or what happens when it is omitted. With 0% schema description coverage, the description was expected to compensate, but it only describes the output fields and never addresses the parameter.
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 clearly identifies the action ('List') and the resource ('active student enrollments'), and the parenthetical grade fields add useful specificity that distinguishes it from generic enrollment or course listing tools. However, it does not explicitly differentiate itself from sibling tools such as canvas_list_courses or canvas_list_observees beyond the resource name.
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 implies usage when an agent needs active student enrollments with grade details, but it provides no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusion criteria, though the purpose is reasonably inferable from the resource and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.