Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Upcoming Events

get_upcoming_events
Read-only

Retrieve the current user's upcoming Canvas calendar events and assignments for the next week, then filter returned items by event, assignment, or sub-assignment type.

Instructions

Get the current user's upcoming calendar events and assignments. Canvas caps this endpoint at roughly the next 1 week and at most 20 events server-side — neither limit is adjustable, and results silently stop there even if more events fall later. For a longer or specific date range, use list_calendar_events with explicit start_date/end_date instead. Canvas does not support filtering this endpoint server-side; type filters the returned items client-side by their own type field ("event", "assignment", or "sub_assignment") instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_upcoming_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoOnly return items of this type ("event", "assignment", or "sub_assignment"). Applied client-side after the fetch — Canvas has no server-side filter for this endpoint.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.20
    • addedInput schema / properties / type
      Added value: +{
+  "description": "Only return items of this type (\"event\", \"assignment\", or \"sub_assignment\"). Applied client-side after the fetch — Canvas has no server-side filter for this endpoint.",
+  "enum": [
+    "event",
+    "assignment",
+    "sub_assignment"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv1.18.11
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv1.18.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint; the description adds the behavior that actually matters here — a hard ~1 week / 20 event server-side cap that is non-adjustable and truncates silently. That silent-truncation warning is exactly the kind of trait an agent cannot infer from schema or annotations.

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?

Four tight sentences, front-loaded with purpose and immediately followed by the limiting behavior that most affects results. Minor redundancy: the client-side-only nature of `type` is stated in the description and again in the schema property text.

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 and a single optional param, the description covers what an agent needs to call it and interpret truncation. It does not say anything about result ordering or the shape of returned items (events vs assignments), a small residual gap.

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

Parameters4/5

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

Schema coverage is 100% and the enum values are documented, so the baseline is 3. The description exceeds it by explaining that `type` is applied client-side after the fetch and does not change what the server returns, which reframes the parameter's meaning rather than restating it.

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

Purpose5/5

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

States a specific verb+resource (get upcoming calendar events and assignments) scoped to the current user, and explicitly distinguishes itself from list_calendar_events, the obvious lookalike sibling. An agent can pick between the two without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (short-horizon upcoming view) and when-to-use-something-else (longer or specific date range → list_calendar_events with start_date/end_date). It also preempts a misuse mode: filtering by type will not surface more events because the fetch limits apply first.

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

Deploy Server

Other Tools