Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read Course File

read_course_file
Read-only

Reads a Canvas course file and returns its content as base64 directly in the response, so clients on different machines can access files without server filesystem downloads.

Instructions

Read a file from a Canvas course and return its content as base64.

Unlike download_course_file which saves to the server's local filesystem, this tool returns the file content directly in the response. This is useful when the MCP server runs on a different machine than the client.

Use list_course_files or list_module_items to find file IDs.

Input Schema

NameRequiredDescriptionDefault
file_idYesCanvas file ID
max_size_mbNoMaximum file size in MB to read (default: 25). Clamped server-side to READ_FILE_MAX_SIZE_MB (default 100). Files larger than the effective limit are rejected to avoid excessive memory usage.
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 / max_size_mb / description
      Added value: +"Maximum file size in MB to read (default: 25). Clamped server-side to\nREAD_FILE_MAX_SIZE_MB (default 100). Files larger than the effective limit are\nrejected to avoid excessive memory usage."
    • removedInput schema / properties / max_size_mb / title
      Removed value: -"Max Size Mb"
    • removedInput schema / title
      Removed value: -"read_course_fileArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"read_course_fileOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  3. Addedv1.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the non-obvious behavioral fact that content is returned inline as base64 rather than persisted to disk, which is what distinguishes it from the write-path sibling. It stops short of noting memory/size implications of base64 payloads, which the schema handles in max_size_mb but a caller reasoning about large files would benefit from hearing once more.

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?

Three short sentences, each doing distinct work: purpose, differentiation, and prerequisite discovery. Front-loaded with the verb and resource, no filler or restatement of the title.

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 three-parameter read tool with full schema coverage, the description covers what it does, what it returns, and how to find inputs. The only gap is that it does not warn that base64 inflates payload size, leaving the agent to infer the practical consequence of the size limit.

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 coverage is 100%, and the schema documents course_identifier, file_id, and max_size_mb including the server-side clamp to READ_FILE_MAX_SIZE_MB. The description adds only the sourcing hint for file_id, which is useful but thin against a fully documented schema, so the baseline 3 applies.

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 ('Read a file from a Canvas course') and immediately states the return form ('content as base64'). It explicitly contrasts with download_course_file, so the agent can distinguish it from its nearest sibling without inspecting 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 both the selecting condition ('useful when the MCP server runs on a different machine than the client') and the alternative ('Unlike download_course_file which saves to the server's local filesystem'). It also routes the agent to list_course_files or list_module_items to obtain the file_id prerequisite.

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