Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Local Edition

by Fireiscoolsolo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Submit Assignment Text

submit_assignment_text
Destructive

Submit text to a Canvas online text-entry assignment, with a dry-run preview first so you can check it before the submission attempt is final.

Instructions

Submit text for an online text-entry assignment, exactly as given; the tool never writes content for you. Your instructor sees it and it counts as a submission attempt. [IRREVERSIBLE: call without confirm=true first to preview, then re-call with confirm=true.]

Input Schema

NameRequiredDescriptionDefault
bodyYesThe submission text (HTML allowed)
commentNoOptional comment to the instructor
confirmNoMust be true to actually execute. Omit or set false to get a dry-run preview first.
course_idYesCanvas course ID, a numeric string such as "12345". Get it from list_courses.
assignment_idYesAssignment ID (numeric string). Get it from list_assignments or list_upcoming_assignments.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.2
    • 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."
  2. First observedv1.0.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the description adds useful context by disclosing that the instructor sees the text, it counts as an attempt, and the call is irreversible unless a dry-run preview is done first. This adds meaning beyond the annotations, though it does not cover permissions or rate limits.

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?

The description is front-loaded with the core purpose and immediately followed by the critical irreversibility and confirm-flow warning. Every sentence carries actionable information with no waste.

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 destructive mutation tool with no output schema, the description covers the key behavioral risks: exact content, instructor visibility, attempt counting, and the preview/confirm workflow. It could be slightly more complete by explicitly naming file/URL submission alternatives, but it is largely adequate.

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 all five parameters, including confirm and body. The description reinforces that body must be exactly as given, but otherwise adds little parameter-level meaning 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?

States a specific verb and resource: submit text for an online text-entry assignment. The phrase 'text-entry assignment' implicitly distinguishes it from submit_assignment_url and submit_assignment_file, and 'exactly as given; the tool never writes content for you' further clarifies its exact purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Provides clear context that this is for online text-entry assignments and that it counts as a submission attempt, but does not explicitly name alternatives such as submit_assignment_url or submit_assignment_file or state when not to use this tool. The usage is implied rather than spelled out.

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