Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Download Course File

download_course_file
Idempotent

Download a file from a Canvas course to your local filesystem for offline use. Use read_course_file to retrieve content without saving.

Instructions

Download a file from a Canvas course to the local filesystem.

Only available on a local (stdio) server. Use read_course_file to get file content back in the response instead.

On Windows, owner-only access is not enforced: files inherit the destination folder's permissions. Use a folder with verified private Windows permissions, or read_course_file to avoid saving a local copy.

Use list_course_files or list_module_items to find file IDs.

Input Schema

NameRequiredDescriptionDefault
file_idYesCanvas file ID
save_directoryNoLocal directory to save to (default: system temp dir, must exist)
course_identifierYesCourse code or Canvas ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.10.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Changed11 schema fields changedv1.8.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / course_identifier / description
      Added value: +"Course code or Canvas ID"
    • removedInput schema / properties / course_identifier / title
      Removed value: -"Course Identifier"
    • addedInput schema / properties / file_id / description
      Added value: +"Canvas file ID"
    • removedInput schema / properties / file_id / title
      Removed value: -"File Id"
    • addedInput schema / properties / save_directory / description
      Added value: +"Local directory to save to (default: system temp dir, must exist)"
    • removedInput schema / properties / save_directory / title
      Removed value: -"Save Directory"
    • removedInput schema / title
      Removed value: -"download_course_fileArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"download_course_fileOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  3. Addedv1.3.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds real behavioral context beyond that: the stdio-only availability, and a non-obvious platform caveat that on Windows owner-only access is not enforced so files inherit the destination folder's permissions. The security workaround (use a verified-private folder or avoid a local copy) is disclosed rather than left to be discovered.

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?

Front-loaded with the core action, then alternatives, then the platform caveat, then ID discovery — a sensible priority order with no filler. The second mention of read_course_file as a Windows fallback is mildly redundant but tied to a distinct risk, so it mostly earns its place.

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 3-parameter, no-output-schema tool with annotations present, the description covers availability constraints, safer alternatives, security caveats, and ID sourcing. The only gap is what a successful call returns (e.g., the saved path or filename), which an agent may want to report back.

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 file_id, course_identifier, and save_directory (including the default temp dir and must-exist constraint) are already documented. The description adds only indirect color — that file_id values come from the list tools and that save_directory choice matters on Windows — without any new syntax or format detail.

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 and resource ('Download a file from a Canvas course') plus the destination ('to the local filesystem'), which immediately separates it from read_course_file. The distinction from the sibling content-reading tool is spelled out, so an agent can choose 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?

Explicitly names the alternative ('Use read_course_file to get file content back in the response instead') and gives discovery guidance ('Use list_course_files or list_module_items to find file IDs'). It also states an environment precondition — only available on a local (stdio) server — which is exactly the kind of when-not guidance agents need.

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