Skip to main content
Glama

canvas_front_page

Read-onlyIdempotent

Reads a course or group’s Canvas front page to retrieve schedules, office hours, and slide links, making key course information easy to locate.

Instructions

Read the front (home) page of a course or group in full. Often holds the schedule, office hours and links to slides; files it links are found by canvas_find_files.

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.
context_idYesId of the course, group, user or folder named by context_type.
context_typeYesWhere to look: course or group (files and folders also take user or folder).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful content context and clarifies that linked files are not returned directly, but it does not address pagination behavior despite the page parameter or explain how raw output differs.

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?

Two compact sentences front-load the operation and then add useful context and a sibling reference. There is no redundant or wasted wording.

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?

For a simple read-only tool with full schema coverage and rich annotations, the description is mostly complete: it covers purpose, typical content, and the linked-file boundary. It leaves pagination and raw-output behavior to the schema rather than describing them directly.

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%, so the schema already documents raw, page, context_id, and context_type. The description only reinforces that context_type may be course or group and does not add meaning for raw or pagination parameters beyond the schema.

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?

The description states a specific verb and resource: reading the front/home page of a course or group in full. The phrase 'front (home) page' distinguishes this from generic page retrieval siblings such as canvas_page, and it names canvas_find_files as the route for linked files.

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?

It gives clear usage context by explaining what the front page often contains and explicitly redirects linked files to canvas_find_files. It does not state when not to use this tool versus canvas_page or canvas_pages, so it falls short of full alternative guidance.

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