Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

by Fireiscoolsolo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Upload Submission File

upload_submission_file

Uploads a local file to an assignment's submission slot without submitting it, returning a file_id for later submission. Use when you need to stage a file before final submission.

Instructions

Upload a local file into an assignment's submission slot without submitting it. Nothing is submitted and your instructor sees nothing yet. Returns a file_id that can be submitted later through raw_canvas_request; submit_assignment_file uploads and submits in one step.

Input Schema

NameRequiredDescriptionDefault
course_idYesCanvas course ID, a numeric string such as "12345". Get it from list_courses.
file_pathYesAbsolute path of the local file to upload, e.g. "C:/Users/me/essay.pdf".
assignment_idYesAssignment ID (numeric string). Get it from list_assignments or list_upcoming_assignments.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.1.3
    • changedInput schema / properties / assignment_id / description
      Previous value: -"Canvas ID (numeric string)"New value: +"Assignment ID (numeric string). Get it from list_assignments or list_upcoming_assignments."
    • changedInput schema / properties / course_id / description
      Previous value: -"Canvas course ID"New value: +"Canvas course ID, a numeric string such as \"12345\". Get it from list_courses."
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path of the local file to upload, e.g. \"C:/Users/me/essay.pdf\"."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true); the description adds the material side-effect detail that nothing is actually submitted and the instructor sees nothing yet, plus what is returned. It omits re-upload/duplicate behavior (relevant given idempotentHint=false) and any size or permission constraints on the upload.

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 earning its place: scope of the action first, then the no-side-effect clarification, then the return value and the alternative tool. The most decision-relevant information (not submitting) is front-loaded, with no filler.

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 write-side tool with no output schema, the description supplies what the structured fields cannot: the non-submitting semantics, the return value (file_id), and the handoff path to submission. Missing only operational envelope details such as file size limits, allowed file types, and behavior on repeated uploads to the same slot.

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%, and each parameter already documents format and how to obtain the IDs, so the schema carries the burden. The description adds only the conceptual notion of a local file path, no format, ordering, or validation nuance beyond the schema. 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 (upload) and resource (a local file into an assignment's submission slot) with an explicit scope qualifier: 'without submitting it'. It also names the sibling that does the combined operation (submit_assignment_file), so an agent can distinguish the two without reading 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 gives both selection paths: use this tool when you want a staged upload, use submit_assignment_file when you want upload+submit in one step. It further explains the downstream step (submit the returned file_id via raw_canvas_request), covering the full workflow rather than just the trigger condition.

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