Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Update Syllabus

update_syllabus
Destructive

Set or edit the Canvas syllabus tab content for a course. Replacing an existing syllabus previews first and requires a confirmation token, while empty, append, or prepend writes take one call.

Instructions

Set the Canvas Syllabus tab content for a course.

Canvas keeps no revision history for the syllabus, so replacing a syllabus that already has content is a two-step call: call without confirmation_token to get a preview plus a single-use token, show the preview to the educator, and only after they approve it call again with the token and identical arguments. Writing into an empty syllabus, or appending/prepending, destroys nothing and takes a single call.

Optional guards, independent of the confirmation token: the syllabus has no updated_at, so expect_body_sha256 (shown by get_syllabus) refuses if the body changed since you read it; find/replace edits one fragment of the current body instead of sending syllabus_body (mode must be "replace", and it still previews first); require lists strings that must already be present.

Input Schema

NameRequiredDescriptionDefault
findNoExact HTML fragment that must occur exactly once in the current body
modeNo"replace" (default) swaps the whole body, "append" adds to the end of the existing body, "prepend" adds to the start.replace
replaceNoText that replaces find (may be empty to delete it)
requireNoStrings that must already be present in the current body
syllabus_bodyNoHTML for the syllabus. Canvas stores this as HTML; plain text is accepted but renders without formatting.
course_identifierYesCourse code or Canvas ID
confirmation_tokenNoToken from the preview call. Only needed when replacing a syllabus that already has content; a token that is supplied is always checked, in every mode.
expect_body_sha256NoSHA-256 of the syllabus body when you read it (get_syllabus prints it); refuse if the body has changed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.15.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint and non-idempotency, and the description adds substantial context beyond them: no revision history, the single-use token lifecycle, that tokens are checked in every mode, and how each guard protects against clobbering. This is exactly the behavioral context the annotations alone cannot convey.

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-loads the core operation and the confirmation flow, with guard details following. Dense but nearly every sentence carries operational weight; the parenthetical mode note is slightly compressed but not wasteful.

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

Completeness5/5

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

An 8-parameter mutation tool with no output schema is fully covered: the preview/token workflow, guard semantics, and destructive implications are all explained. Nothing an agent needs to call it safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are documented, but the description adds cross-parameter meaning: find/replace requires mode='replace' and still previews, confirmation_token interacts with content state, and guards operate independently. It stops short of covering every parameter (e.g., course_identifier, mode's full enum), so not a 5.

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 ('Set') and resource ('Canvas Syllabus tab content for a course'), which unambiguously separates it from the read-only sibling get_syllabus. An agent can identify the operation without opening the 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 lays out when a two-step preview/confirm flow is required (replacing non-empty syllabus) versus when a single call suffices (empty syllabus, append/prepend), and names get_syllabus as the source for expect_body_sha256. It even specifies the sequencing (show preview, then call with token and identical args).

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