Overview

Source: github.com/JohannsenLum/canvas-api-mcp · MIT

What it is

canvas-api-mcp is an MCP server for Canvas LMS. It lets an AI agent — Claude Code, Claude Desktop, Cursor, or anything else that speaks MCP — read and act on a student's own Canvas account: what's due, current grades, course content, discussions, and submitting work.

It ships with 15 curated tools shaped around real student questions ("what's due this week?", "how am I doing in CS3230?"), plus a 2-tool gateway that reaches every other endpoint the Canvas instance exposes. Together that's 17 tool schemas reaching all 1,116 endpoints on a stock Instructure Canvas deployment.

Who it's for

Phase 1 is student-scoped and personal-use. The author is the first user (an NUS student); NUS peers are the first distribution target. A student's personal access token reaches only that student's own data — grades, courses, submissions — which keeps the design free of any third-party personal-data handling and makes every tool live-testable against a real account.

There are no curated educator tools yet. That's not a capability gap — Canvas enforces permissions per token on its own servers, so the gateway already reaches educator endpoints and works the moment a teacher token is used, with no code change. Curated educator ergonomics are deferred to a later phase. See Compliance for why general distribution is a separate, unresolved question from the code itself.

Three-layer architecture

Exposing 1,116 endpoints as 1,116 tools isn't viable — tool-selection accuracy degrades as the list grows, and every schema costs context on every turn. Exposing only a curated subset permanently orphans the long tail. So the server layers three things over one HTTP client instead:

"what's due this week"      -> Layer 1, one call, no discovery
"my grade breakdown"        -> Layer 1, one call
"list my group memberships" -> Layer 2 finds GET /users/self/groups
                             -> Layer 3 executes it

Real usage is extremely concentrated — two endpoints out of 1,116 answer "what's due this week?" — but the long tail is genuinely needed and unpredictable. Fifteen curated tools cover the concentrated part with real ergonomics; the gateway covers everything else without anyone having to hand-write a tool for it.

Why 17 tools reach all 1,116 endpoints

Authorisation is Canvas's job, not the server's. Every request carries the user's bearer token and Canvas decides what it permits — the server never simulates, predicts, or pre-filters permissions, it just surfaces Canvas's answer. Because of that, the gateway's reach isn't capped by which tools are curated: search_canvas_api

• canvas_request can drive any of the 1,116 endpoints in the catalog, and what actually succeeds depends only on the token's role. A teacher token reaches educator endpoints through the same two tools, unchanged.

Where to go next