Compliance

This page states the compliance position plainly, because the position itself limits what this software is for. Not legal advice — consult your institution's IT department before distributing anything built on it.

The hard boundary: personal tokens are for personal use

Instructure's OAuth2 documentation is explicit on this point: manually generated personal access tokens are intended for testing, asking any other user to manually generate a token and enter it into your application is a violation of Canvas' API Policy, and applications in use by multiple users must use OAuth to obtain tokens.

That produces a fixed boundary around this project:

Phase 1 is for personal use and source publication only. Publishing the source is unaffected by any of this — code is not a Canvas integration until someone runs it against their own account. Turning this into something other users are told to install requires an answer to how those users authenticate, and that answer is not purely a coding decision.

Tokens never reach the author under any configuration: each user's token stays in their own MCP client config, on their own machine, and is sent only to their own CANVAS_BASE_URL. That removes credential-custody risk, but it does not resolve the policy point above — the policy concerns the instruction to mint and hand over a token, not where the token is subsequently stored.

Why not just add OAuth

Because Canvas OAuth2 doesn't support it safely for software like this. Canvas's OAuth implementation has no PKCE and no public-client handling — verified against Instructure's own oauth.md and oauth_endpoints.md reference docs, neither of which defines a code_challenge, a code_verifier, or a public-client flow, and both of which require a client_secret for the token exchange.

Locally installed software cannot hold a client_secret safely: every copy of the package would embed the same secret, and it is trivially extractable from an installed Python package. That would be worse than personal tokens, not better — it replaces one password-equivalent credential with a shared one that every installation leaks by existing.

The remaining paths to general distribution all require someone other than the author to act:

This is why distribution is blocked on an authentication answer, not on writing more code — and why the next step is asking the institution how it would prefer students to authenticate, rather than picking an approach and presenting it as settled.

Why not just host it

No hosted or shared deployment is planned. Every user runs their own local process with their own token. Hosting would mean the operator custodying other people's Canvas credentials — full read access to grades, messages, and submission rights, for every user, in one place. That is a large liability with no offsetting benefit over the current model, where a leak is scoped to one account.

Academic integrity

submit_assignment will submit whatever content it is given — including AI-generated work — the moment it is called, against the real deadline, visible to the instructor immediately. Submitting work that is not genuinely your own breaches the academic integrity policy of essentially every institution, and Canvas's API Policy separately prohibits use that violates an institution's academic integrity rules. The tool does not and cannot distinguish your own work from generated work; that distinction is the caller's responsibility, every time.

Rate limiting

Canvas's API Policy prohibits interfering with or overloading its systems. The client throttles requests as the account's X-Rate-Limit-Remaining quota approaches zero and backs off on a rate-limit response. This is not a tunable optimisation — it is a compliance requirement, and it must not be removed, disabled, or bypassed by any tool, including the gateway.

Copyright on course materials

read_file retrieves course materials — slides, notes, readings — for the requesting user's own study. It does not cache files to any shared location, and nothing about the design encourages redistributing what it fetches. Course materials generally remain the copyright of the instructor or institution; downloading your own copy to study from is not the same as being entitled to share it further.

A Canvas token is password-equivalent

A personal access token grants the same access as logging in: it can read grades, read private instructor messages, and submit work, all under your identity. It is stored in plaintext in your MCP client's config file — that is an explicit design choice for phase 1, not an oversight, and it's the same storage model every other locally configured MCP server credential uses. Because of that:

• Set an expiry date when you mint it — a term length is a reasonable default — rather than accepting "never."
• Never commit it to a repository, and treat your MCP client config the way you'd treat any other file holding a password.
• If a token leaks, revoke it from Canvas immediately: Account → Settings → Approved Integrations.

Institution availability and feature variance

Student personal-access-token generation is not guaranteed everywhere; it was confirmed available at NUS on 2026-08-07 but remains a prerequisite your own institution may not meet. Separately, individual endpoints in the catalog can return "not found" either because the resource genuinely doesn't exist, isn't visible to your account, or because that feature is disabled at your institution — the server's error messages are written to distinguish these where possible, but a 404 is still a 404.

Personal data

A student token reaches only that student's own data, so phase 1 processes no third-party personal data. This is a direct consequence of the student-scoped design, not a policy promise layered on top of a broader tool. It changes the moment educator tools process other students' grades or messages, which is why that phase is gated on a data-governance review — including Singapore PDPA obligations and institutional data-classification rules for transferring student data to external AI services — before any code for it ships.