Skip to main content
Glama
Sign In
Canvas LMS MCP Server

Canvas LMS MCP Server

by bruchris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Page

get_page
Read-only

Get one wiki page by its page_url slug — not a numeric ID — obtained from list_pages. Returns the page's title, published state, editing_roles and full HTML body, unlike the list endpoint's body-less stubs.

Instructions

Get one wiki page by its page_url slug — not a numeric ID — obtained from list_pages. Returns the page's title, published state, editing_roles and full HTML body, unlike the list endpoint's body-less stubs. Use list_pages to discover a course's pages and find a page_url, and update_page to edit this page's title, body, published state or editing_roles afterward.

Input Schema

NameRequiredDescriptionDefault
page_urlYesThe page URL slug (e.g. "welcome-page")
course_idYesThe Canvas course ID

Output Schema

NameRequiredDescriptionDefault
urlYes
bodyNo
titleYes
page_idYes
publishedNo
created_atNo
updated_atNo
editing_rolesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.18.15
    • addedInput schema / properties / course_id / anyOf
      Added value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[1-9][0-9]{0,18}$",
+    "type": "string"
+  }
+]
    • removedInput schema / properties / course_id / type
      Removed value: -"number"
    • changedOutput schema / properties / page_id / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
  2. Changed2 schema fields changedv1.18.11
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changedv1.18.9
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "body": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "created_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "editing_roles": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "page_id": {
+      "type": "number"
+    },
+    "published": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "title": {
+      "type": "string"
+    },
+    "updated_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "page_id",
+    "url",
+    "title"
+  ],
+  "type": "object"
+}
  4. First observedv1.18.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuine context by enumerating the returned fields (title, published state, editing_roles, full HTML body) and contrasting them against the list endpoint's stubs. It stops short of noting pagination or size concerns, which is a minor gap for a full-body fetch.

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?

Two sentences, front-loaded with the identity and key constraint (slug, not ID), then the return payload, then the alternatives. Every clause carries information an agent would otherwise have to guess.

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 output schema exists, so return values need not be spelled out, yet the description still gives a useful preview of the payload shape. With only two fully documented parameters and covered annotations, nothing needed to invoke the tool correctly 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% and the schema already labels page_url as a slug, but the description adds meaning the schema does not: that it is explicitly not a numeric ID and that it comes from list_pages. That prevents a common misuse and lifts it above the baseline 3.

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 (get one wiki page) and immediately scopes it to a page_url slug rather than a numeric ID. It explicitly contrasts with list_pages, which returns body-less stubs, so an agent can distinguish the two without opening 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 explicit routing: use list_pages to discover a course's pages and obtain a page_url, and update_page to modify title, body, published state or editing_roles. Both the precondition and the follow-on alternative are named rather than inferred.

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