Canvas MCP Server

Overview Schema Source Related Servers Discussions Admin

Edit Page Content

edit_page_content

DestructiveIdempotent

Replace a Canvas page's HTML body or edit one fragment with find/replace. Optional guards refuse the write if the page changed since you read it, then verify the result.

Instructions

Replace the HTML body of a page (and optionally its title).

new_content becomes the whole body: it is not merged or appended, so pass the complete page, not a fragment. To change one fragment, pass find and replace instead of new_content. Publishing state, editing roles, and front-page status are unchanged; use update_page_settings.

Optional guards (any of them makes the tool fetch the page first, refuse rather than write on a failed check, and read the page back after): expect_updated_at refuses if the page changed since you read it; find/replace edits one fragment of the current body; require lists strings that must already be present.

Input Schema

Name	Required	Description
`find`	No	Exact HTML fragment that must occur exactly once in the current body
`title`	No	Optional new title for the page
`replace`	No	Text that replaces find (may be empty to delete it)
`require`	No	Strings that must already be present in the current body
`new_content`	No	Complete new HTML body (replaces the old body). Omit when using find/replace.
`page_url_or_id`	Yes	Page URL slug or page ID
`course_identifier`	Yes	Course code or Canvas ID
`expect_updated_at`	No	The page's updated_at when you read it; refuse if it has changed

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.15.0Oct 24, 2026

addedInput schema / properties / expect_updated_at

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The page's updated_at when you read it; refuse if it has changed"
+}

addedInput schema / properties / find

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Exact HTML fragment that must occur exactly once in the current body"
+}

addedInput schema / properties / new_content / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / new_content / default
```
Added value: +null
```

changedInput schema / properties / new_content / description

Previous value: -"New HTML content for the page"New value: +"Complete new HTML body (replaces the old body). Omit when using find/replace."

removedInput schema / properties / new_content / type
```
Removed value: -"string"
```

addedInput schema / properties / replace

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Text that replaces find (may be empty to delete it)"
+}

addedInput schema / properties / require

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Strings that must already be present in the current body"
+}

changedInput schema / required

Previous value: -[
-  "course_identifier",
-  "page_url_or_id",
-  "new_content"
-]New value: +[
+  "course_identifier",
+  "page_url_or_id"
+]

Changed1 schema field changedv1.10.0Aug 20, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changed13 schema fields changedv1.8.0Aug 10, 2026
- 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 / new_content / description
```
Added value: +"New HTML content for the page"
```
- removedInput schema / properties / new_content / title
```
Removed value: -"New Content"
```
- addedInput schema / properties / page_url_or_id / description
```
Added value: +"Page URL slug or page ID"
```
- removedInput schema / properties / page_url_or_id / title
```
Removed value: -"Page Url Or Id"
```
- addedInput schema / properties / title / description
```
Added value: +"Optional new title for the page"
```
- removedInput schema / properties / title / title
```
Removed value: -"Title"
```
- removedInput schema / title
```
Removed value: -"edit_page_contentArguments"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"edit_page_contentOutput"
```
- addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```
Changed1 schema field changedv1.0.0Jan 3, 2026
- addedInput schema / title
```
Added value: +"edit_page_contentArguments"
```
First observedSep 27, 2025

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare idempotentHint and destructiveHint; the description adds substantial context beyond that — the body is fully overwritten rather than merged, guards cause a fetch-first + refuse-on-failure + read-back-after cycle, and settings/roles/front-page are left untouched. This materially changes how an agent should prepare arguments (complete page vs fragment) and is the kind of behavioral detail annotations 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?

The replacement semantics and the sibling pointer are front-loaded, and the guard behavior is grouped into a single paragraph. It is dense rather than padded, though the parenthetical restatement about fetching/refusing/reading back repeats a mechanism already implied per-parameter.

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 an 8-parameter mutation with no output schema, the description covers destructive scope, mode selection, and guard behavior well. The remaining gap is that it does not say what the tool returns after the read-back (e.g., refreshed body/updated_at) nor how conflicting new_content + find inputs are resolved, which an agent would need for recovery on refusal.

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 baseline is 3, but the description goes further by explaining the interaction between parameters: new_content is a complete replacement and should be omitted when using find/replace, find must occur exactly once, and each guard (expect_updated_at, find/replace, require) triggers fetch/refuse/read-back semantics. It does not clarify what happens if new_content and find are supplied together, leaving one small ambiguity.

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?

The first sentence states a specific verb and resource ('Replace the HTML body of a page') and immediately bounds scope ('and optionally its title'). It also distinguishes itself from update_page_settings by naming what it does not touch (publishing state, editing roles, front-page status), so an agent can separate it from siblings like update_page_settings, bulk_update_pages, and create_page without opening schemas.

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?

It explicitly routes between two modes: pass new_content for a full-body rewrite, or pass find/replace for a single fragment, and warns that new_content is not merged. It also names the sibling to use for settings ('use update_page_settings') and explains the opt-in guard conditions, which is exactly the when-to-use guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Edit Page Content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools