Skip to main content
Glama

canvas_agenda

Read-onlyIdempotent

Reads Canvas planner work plus calendar events and assignment dates for specified course IDs, returning per-source completeness or errors for a date range.

Instructions

Read planner work and, for explicit course IDs, calendar events AND assignment dates.

Use ISO dates or timestamps with an explicit offset. Calendar batches at most ten contexts. Planner alone is not a complete institutional timetable. Each source reports its own completeness/error rather than hiding failures.

Input Schema

NameRequiredDescriptionDefault
end_dateYes
course_idsNo
start_dateYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description still adds real context: ISO dates with an explicit offset are required, calendar calls cap at ten contexts, planner data is not a complete timetable, and each source reports its own completeness/errors instead of silently failing.

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

Conciseness4/5

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

Short and front-loaded: the main capability comes first, followed by format requirements, a limit, and a caveat. The telegraphic, fragment-heavy phrasing costs a little readability but nearly every sentence carries information.

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?

A read-only, annotated tool with an output schema needs less return-value explanation, and the description supplies the key caveats an agent would otherwise miss: date formatting, batch limits, incomplete planner coverage, and per-source error reporting. Only the course_ids-omitted behavior is left implicit.

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 0%, so the description must carry the parameter burden. It clarifies date format (ISO with explicit offset) and that course_ids gates calendar/assignment retrieval, which adds value. It does not explain the course_ids format, the null default (planner-only), or the array-of-strings shape, leaving gaps.

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?

States a specific verb (read) and names the three resources it spans: planner work, calendar events, and assignment dates. The sibling set includes canvas_assignments and canvas_courses, and the description implies this tool is the cross-source agenda view rather than a single-resource reader, though it never names that distinction explicitly.

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

Usage Guidelines3/5

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

"For explicit course IDs" and "Planner alone is not a complete institutional timetable" imply when each source applies, and the ten-context batch limit hints at chunking. But there is no explicit statement of when to use this tool versus canvas_assignments or canvas_courses, and no guidance on what happens when course_ids is omitted.

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