Skip to main content
Glama

canvas_appointment_groups

Read-onlyIdempotent

Read Canvas appointment groups, available times, and your reservations without booking anything. Use it to check scheduling options and existing appointments.

Instructions

Read available Canvas appointment groups, times and your reservations; does not book anything.

Input Schema

NameRequiredDescriptionDefault
rawNotrue: Canvas's unmodified JSON (UTC times, HTML).
pageNoPage to fetch: a number, or the next_page value returned by the previous call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's 'does not book anything' restates read-only intent and adds the useful scope note that results include times and the caller's own reservations, but says nothing about pagination behavior or what 'available' means (course vs. user scoped).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the resource enumerated first and the negative scope at the end. Every clause earns its place and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully signals the shape of the return data (groups, times, your reservations), which is exactly the gap structured fields leave. It would be complete with one more clause on whether results are limited to the current user or span all enrolled courses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters ('raw' and 'page', including the bookmark pattern) are fully documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') plus a clearly enumerated resource set (appointment groups, their times, and the caller's own reservations), and it explicitly negates the adjacent action with 'does not book anything'. It stops short of naming the singular sibling canvas_appointment_group, so the list-vs-detail boundary is only implied by the plural.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'does not book anything' gives an explicit when-not, steering an agent away from treating this as a booking or mutation tool. No alternative tool is named, so an agent that needs per-group detail has to infer that canvas_appointment_group is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.