Skip to main content
Glama

canvas_list_course_files

Read-only

List files in a Canvas course and view their metadata; use the returned url with the download tool to fetch file contents.

Instructions

List a course's files (metadata only — use canvas_download_file with the url field).

Input Schema

NameRequiredDescriptionDefault
courseIdYes
searchTermNo
contentTypesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv1.2.5

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely useful behavioral context by clarifying that no file content is returned and that the `url` field is the handoff point to the download tool. It stops short of mentioning pagination, rate limits, or auth scope.

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 front-loaded sentence that leads with what the tool returns and immediately follows with the alternative it is not. Zero wasted words.

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

Completeness3/5

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

For a simple read-only listing tool with no output schema this is close to adequate, since the return shape is described conceptually. The missing documentation of the two optional filter parameters is the notable gap that keeps it from being complete.

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

Parameters2/5

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

Schema description coverage is 0% and the description says nothing about the three parameters, leaving searchTerm and contentTypes completely undocumented in both places. The only field mentioned (`url`) is a return value, not an input, so the description does not compensate for the schema gap.

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 ('List a course's files') and explicitly distinguishes the tool from its closest sibling by noting it returns metadata only versus canvas_download_file. An agent can tell the two apart 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 Guidelines4/5

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

It names the alternative (canvas_download_file) and the condition that selects it ('metadata only — use canvas_download_file with the `url` field'), giving clear routing guidance. It does not, however, say when to prefer this tool's searchTerm/contentTypes filtering over just listing everything.

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