What can you do with this server?

This server exposes the Canvas LMS REST API as MCP tools, allowing you to interact with your Canvas courses and academic data from any MCP-compatible client (e.g., Claude Code, Claude Desktop). * List Courses (list_courses): Retrieve enrolled courses, with optional filtering to active-only. Returns course ID, name, course code, and term. * List Assignments (list_assignments): Get assignments for a specific course, including due dates, point values, and submission status. Optionally include submission details. * List Modules (list_modules): View course modules and their items/contents for a given course. * List Announcements (list_announcements): Fetch announcements posted in a specific course. * Get Wiki Page (get_page): Retrieve a course wiki page's content by its URL slug and course ID. * Get File Info (get_file_info): Look up file metadata, including download URL, for a specific course file. * Get Grades (get_grades): Check current grades for a specific course or across all enrollments. * Planner Items (planner_items): Fetch Canvas planner items (assignments, events) for a specified date range. * Upcoming Events (upcoming_events): See upcoming assignments and calendar events across all courses for roughly the next two weeks. * Todo List (todo): View your Canvas TODO list of ungraded or pending assignments. * Bulk Dump (canvas-local-mcp-dump): Perform a bulk download of all accessible course materials and syllabi for offline indexing.

Which integrations are available for this server?

Provides tools for interacting with Canvas LMS via its REST API, including listing courses, assignments, modules, announcements, retrieving page and file information, grades, planner items, upcoming events, and todo items, as well as a bulk file dump capability.

canvas-mcp

by admin978

Overview Schema Related Servers Score Discussions

Python

Local

Canvas LMS MCP Server (`canvas-mcp`)

PyPI Python License

Ask Claude about your Canvas courses, assignments, deadlines, modules, and grades from one place.

canvas-mcp is a local-first MCP server for Canvas LMS users (students, instructors, and MCP builders). It turns Canvas REST API actions into MCP tools that work from Claude Code, Claude Desktop, and other MCP-compatible clients.

Status: alpha. Single-user, no warranty, API surface may still shift. File issues if it breaks.

Who this is for

Students who want one view across multiple courses
Educators who want faster access to assignments, modules, and announcements
MCP users who want Canvas data in local Claude workflows

Related MCP server: Canvas MCP Server

What you can ask Claude

“What assignments are due this week across all my active courses?”
“Show upcoming events and planner items for next week.”
“List my current grades by course.”
“Get the modules (with items) for course 12345.”
“Show announcements for course 12345.”
“Fetch the page syllabus from course 12345.”

Quick start

Prerequisite: Python 3.10+.

1) Create a Canvas personal access token

In Canvas: Account → Settings → Approved Integrations → + New Access Token. Copy the token shown (Canvas does not show it again later).

2) Install

From PyPI (recommended):

pip install canvas-local-mcp

Or from source:

git clone https://github.com/admin978/canvas-mcp.git && cd canvas-mcp
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

3) Configure `~/.canvas.env`

curl -fsSL https://raw.githubusercontent.com/admin978/canvas-mcp/main/.canvas.env.example -o ~/.canvas.env
chmod 600 ~/.canvas.env
# edit ~/.canvas.env: set CANVAS_BASE_URL (institution root, no /api/v1)
# and paste the token into CANVAS_TOKEN

For token safety guidance (least privilege, file permissions, rotation/revocation, and vulnerability reporting), see SECURITY.md.

4) Register in your MCP client

Claude Code:

claude mcp add canvas-local -- canvas-local-mcp

Claude Desktop:

macOS example path: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows example path: %APPDATA%\Claude\claude_desktop_config.json
Linux example path: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "canvas-local": {
      "command": "canvas-local-mcp"
    }
  }
}

Tools exposed

list_courses
list_assignments
list_modules
list_announcements
get_page
get_file_info
get_grades
planner_items
upcoming_events
todo

Bulk dump

canvas-local-mcp-dump downloads course files and related content for offline indexing.

canvas-local-mcp-dump              # all active courses
canvas-local-mcp-dump 12345 67890  # specific course IDs

Output goes to ./canvas-dump/ by default. Override with CANVAS_DUMP_DIR=/path/to/dir.

Local-first, privacy and token flow

The server runs locally and uses stdio transport with your MCP client.
Configuration is read from ~/.canvas.env (CANVAS_BASE_URL, CANVAS_TOKEN).
Requests go from your local server to the official Canvas API endpoints.
No external token broker is used in the request path.
Security guidance and disclosure policy: SECURITY.md.

Demo

No demo GIF is currently committed yet. You can still verify the workflow quickly:

Try these prompts

After registering the MCP server, ask Claude:

“List my active Canvas courses.”
“What assignments are due this week across all my active courses?”
“Show upcoming events and planner items for next week.”
“List my current grades by course.”

Placeholder: add a short terminal/GIF walkthrough here in a future PR.

Development

Requires Python 3.10+.

pip install -e ".[dev]"
ruff check canvas_local_mcp tests   # lint
pytest                              # tests run against a mocked Canvas API — no token needed

CI runs lint + tests on Python 3.10–3.13 for every push and pull request.

Publishing a new release

Follow this order to publish a new version (e.g. 0.1.4) consistently across PyPI and the MCP Registry.

1. Bump the version everywhere

Update all three files to the new version string in a single PR:

File	Field
`pyproject.toml`	`[project].version`
`canvas_local_mcp/__init__.py`	`__version__`
`server.json`	root `version` and `packages[0].version`

The CI test test_server_json_version_matches_package and the workflow validation step will fail if any of these three disagree.

2. Merge the PR into `main`

Wait for all CI checks to pass before merging.

3. Publish `canvas-local-mcp` to PyPI

The project uses Trusted Publisher (OIDC) for PyPI uploads. Trigger the PyPI publish workflow (or run python -m build && twine upload dist/* if you have credentials configured) before creating the tag, so the package is available when the MCP Registry fetches it.

4. Create and push the tag `vX.Y.Z`

git tag v0.1.4
git push origin v0.1.4

This triggers the Publish to MCP Registry workflow, which:

Validates that server.json, pyproject.toml, and the tag all declare the same version.
Publishes server.json to the MCP Registry via GitHub OIDC (no secrets needed).

5. Verify

PyPI: https://pypi.org/project/canvas-local-mcp/
MCP Registry: https://registry.modelcontextprotocol.io/?q=canvas-mcp
GitHub Actions: https://github.com/admin978/canvas-mcp/actions

Important: never reuse or move an existing tag. If you need to re-publish after a mistake, bump to the next patch version (e.g. 0.1.4) and start from step 1.

Contributing, roadmap and support

Issues / feature requests
Pull requests are welcome for bug fixes and Canvas workflow improvements
Roadmap direction currently lives in open issues and upcoming PRs

If this project helps you manage Canvas with Claude, please try the flow above and consider giving it a ⭐ so other students and educators can find it.

License

MIT — see LICENSE.

Built by AGENTE 404 S.L. · admin@agente404.com

Available Tools

10 tools

get_file_infoC

Get file metadata including download url.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes
`file_id`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states it gets metadata, but omits any side effects, error scenarios, or access requirements. Minimal behavioral insight.

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?

Description is a single efficient sentence with no wasted words. However, it could be slightly expanded to include more context without harming conciseness.

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

Completeness2/5

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

Given no output schema, the description should explain the return value more thoroughly. Mentioning 'metadata including download url' is insufficient; it lacks details on other metadata fields, error handling, and required permissions.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no meaning to the parameters (course_id, file_id). It does not explain their roles or expected values beyond what the schema already shows.

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?

Description clearly states the verb 'Get' and the resource 'file metadata', and specifies a key detail 'including download url'. This distinguishes it from sibling tools like get_grades or list_courses which have different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_courses or get_page. No prerequisites or exclusion criteria mentioned.

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

get_gradesB

Current grades. Per-course if course_id provided, otherwise all enrollments.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It describes the tool as returning 'current grades,' implying a read operation, but it does not explicitly state read-only nature, latency, or other behaviors like whether data is cached or if there are access restrictions.

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?

The description is extremely concise at two sentences, with the key information front-loaded ('Current grades.'). Every word adds value, making it efficient for an AI agent to parse.

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

Completeness3/5

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

The description covers the tool's purpose and parameter behavior sufficiently, but it omits details about the output format despite having an output schema. It does not mention data freshness, authentication, or other contextual cues that could be helpful.

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?

With 0% schema description coverage, the description compensates well by explaining the conditional behavior of the course_id parameter: per-course if provided, otherwise all enrollments. This adds clear meaning beyond the schema's type and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves current grades and distinguishes between per-course and all enrollments based on the course_id parameter. While it is specific, it could more explicitly differentiate from sibling tools like list_assignments, but the focus on grades is adequate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use the tool with a course_id versus without, but it does not mention when not to use it or suggest alternatives among siblings. This is acceptable for a simple tool but lacks broader usage context.

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

get_pageB

Fetch a course wiki page by its url slug.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes
`page_url`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so description must carry full burden. It only states 'fetch' without disclosing error behavior, authentication needs, or result format. The description is too minimal for a tool with no annotations.

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?

Single sentence of 9 words, front-loaded with action and resource. No wasted words.

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

Completeness3/5

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

For a simple fetch tool with 2 parameters and no output schema, the description covers the basic operation but lacks details on return values, error cases, and parameter format. It is adequate but incomplete.

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

Parameters3/5

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

Schema has 0% description coverage beyond titles. Description adds that page_url is a slug, which provides some semantic meaning. However, course_id is unexplained, and the description does not fully compensate for missing schema descriptions.

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?

Description clearly states 'Fetch a course wiki page by its url slug.' It specifies the verb, resource, and method. It distinguishes from siblings like get_file_info which handles files, not wiki pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines provided. Description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The agent receives no guidance on context.

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

list_announcementsD

Course announcements.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether this is a read operation, what data is returned, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely brief (two words) to the point of under-specification. It is not concise in a helpful way; it omits essential information.

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

Completeness2/5

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

For a simple tool with one parameter and an output schema, the description is incomplete. It fails to clarify what announcements are listed, which course, or any filtering. The output schema exists but is not referenced.

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

Parameters1/5

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

Input schema has one required parameter (course_id) with 0% description coverage. The description 'Course announcements' adds no meaning to the parameter or its usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description 'Course announcements' is vague; it restates the topic but fails to specify the action (listing). The tool's name implies listing, but the description adds little clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool, prerequisites, or alternatives. Sibling tools like list_assignments or planner_items might overlap, but no differentiation is provided.

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

list_assignmentsB

List assignments in a course. Includes due_at, points, submission status.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes
`include_submissions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. The term 'list' implies a read-only operation, but the description does not explicitly confirm safety, state auth requirements, or describe any side effects. It is adequate but lacks depth.

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 description is a single sentence that conveys the core purpose efficiently. However, it could be slightly expanded to improve clarity without harming conciseness.

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

Completeness3/5

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

Given the presence of an output schema and only two parameters, the description is minimally complete. However, it omits explanation of the key 'include_submissions' parameter, which reduces completeness. It suffices for a simple list operation but leaves gaps.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no meaning to the parameters. 'include_submissions' is not explained, and the description fails to clarify how it affects results. This is a significant gap for a tool with only two parameters.

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 description clearly states the tool lists assignments in a course and specifies the included fields (due_at, points, submission status). It uses a specific verb+resource pattern, distinguishing it from sibling tools like list_courses or list_announcements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. There is no mention of exclusion criteria or references to sibling tools. The description only implies usage for listing assignments without context.

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

list_coursesC

List enrolled courses. Returns id, name, course_code, term.

ParametersJSON Schema

Name	Required	Description	Default
`active_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided, and the description only states the basic action and returned fields, lacking details on side effects or limitations.

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 description is concise at one sentence, but could be more structured by including parameter info.

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

Completeness2/5

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

Given the sibling tools and the output schema, the description lacks parameter elaboration and usage context, making it incomplete.

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

Parameters1/5

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

The schema has one parameter (active_only) with default true, but the description provides no explanation of its meaning or purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List enrolled courses' and lists returned fields, but does not differentiate from sibling list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like list_assignments or list_modules.

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

list_modulesC

Course modules with items.

ParametersJSON Schema

Name	Required	Description	Default
`course_id`	Yes
`with_items`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

Without annotations, the description bears full responsibility for behavioral disclosure. It does not mention read-only nature, pagination, sorting, or any side effects. The simple phrase 'with items' hints at output structure but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though extremely concise (3 words), this result is under-specification rather than efficient communication. The description lacks structure and fails to earn its place by providing essential context.

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

Completeness2/5

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

Given only 2 parameters and an existing output schema, the description is still incomplete. It does not describe the purpose of 'with_items', the type of items returned, or any special behavior. The agent needs more to use this tool correctly.

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

Parameters2/5

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

The input schema has 0% description coverage. The description adds almost no meaning beyond parameter names; 'with_items' is vaguely referenced by 'items', but 'course_id' is not elaborated. The description does not clarify parameter roles or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Course modules with items' vaguely indicates the tool deals with modules and items but does not explicitly state the action (listing). The name 'list_modules' clarifies, but siblings like 'list_announcements' and 'list_assignments' suggest a pattern, so it is somewhat clear but minimal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'get_page' or 'list_assignments'. There is no context about prerequisites, limitations, or recommended scenarios.

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

planner_itemsD

Planner items for the user. ISO dates (YYYY-MM-DD).

ParametersJSON Schema

Name	Required	Description	Default
`start_date`	No
`end_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.9/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only, safety, authentication needs, or side effects. It only mentions date format, offering no transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence), which is concise, but it lacks essential information, so it is under-specified rather than efficient.

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

Completeness2/5

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

Despite having an output schema, the description does not explain what the output contains. For a tool that lists planner items, critical details about filtering, pagination, or data structure are missing.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only mentions 'ISO dates (YYYY-MM-DD)' without explicitly linking to parameters start_date and end_date. It adds minimal meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Planner items for the user' is vague and tautological, restating the tool name without specifying an action (e.g., list, retrieve). It does not distinguish from siblings like 'todo' or 'upcoming_events'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., 'todo' or 'upcoming_events'). The description provides no context for selecting this tool.

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

todoA

User's TODO list (ungraded assignments to look at).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It states the tool returns a filtered list of ungraded assignments, implying read-only behavior, but does not detail ordering, pagination, or other traits. Adequate but minimal.

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?

Single clear sentence, front-loaded. Slightly too terse; could include a brief usage note without losing conciseness.

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?

Given zero parameters and presence of an output schema, the description sufficiently defines the tool's purpose and what it returns. No gaps.

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?

Input schema has zero parameters, so baseline score is 4. Description adds no parameter info since none exist, but that is appropriate.

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?

Clearly states that the tool returns the user's TODO list of ungraded assignments. The phrase 'to look at' implies retrieval, and 'ungraded assignments' distinguishes it from sibling tools like list_assignments or planner_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for ungraded assignments but does not contrast with siblings like list_assignments or upcoming_events.

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

upcoming_eventsA

Upcoming planner items (assignments, calendar events) across all courses. Canvas returns roughly the next two weeks.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral traits. It discloses the time window (next two weeks) and scope (all courses), but does not mention whether it's read-only, how items are ordered, or any other side effects. Adequate but not comprehensive.

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 concise sentences that front-load the essential information. Every sentence adds value: first describes content, second adds time context. No wasted words.

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?

Given zero parameters, no annotations, and presence of an output schema, the description covers the essential context (what items, scope, time range). It could mention ordering or format, but output schema likely handles that. Complete for a simple list tool without missing crucial gaps.

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?

The input schema has zero parameters, so schema coverage is trivially 100%. Per rule, no parameters baseline is 4. The description does not need to add parameter information.

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?

Description clearly specifies the tool returns upcoming planner items (assignments, calendar events) across all courses with a time window. It distinguishes from siblings like 'planner_items' by emphasizing the 'across all courses' scope and the 'roughly next two weeks' range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (returns upcoming items across courses with a time limit) but does not explicitly state when to use this tool versus alternatives like 'planner_items' or 'todo'. No exclusion criteria or when-not-to-use guidance provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.1May 12, 2026
- First observedget_file_info
- First observedget_grades
- First observedget_page
- First observedlist_announcements
- First observedlist_assignments
- First observedlist_courses
- First observedlist_modules
- First observedplanner_items
- First observedtodo
- First observedupcoming_events

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation4/5

Tools target distinct Canvas resources (courses, assignments, modules, etc.), but planner_items and upcoming_events have overlapping purposes, and todo may overlap with assignments. Descriptions help clarify but some ambiguity remains.

Naming Consistency3/5

Naming mixes consistent get_ and list_ prefixes for most tools, but planner_items, todo, and upcoming_events lack any prefix, breaking the pattern. Within their groups, conventions are followed.

Tool Count5/5

10 tools is well-scoped for a Canvas LMS integration, covering all common read-only resources without being too few or too many. Each tool serves a clear purpose.

Completeness3/5

The tool set is read-only, missing any create, update, or delete operations. For a full Canvas integration, this is a notable gap, but within a read-only scope it covers courses, assignments, modules, announcements, files, grades, pages, and planner items.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
111

Related MCP Servers

Canvas MCP
Education & Learning Tools Content Management Systems
overtimepog
F
license
Not graded
quality
D
maintenance
MCP server for Canvas LMS that exposes courses, assignments, modules, pages, files, grades, and submissions as tools for AI agents.
Updated 5 months ago (2026-04-04 16:23 UTC)
-
Canvas MCP Server
Education & Learning Tools Content Management Systems
jordanlein
A
license
Not graded
quality
C
maintenance
A remote MCP server for querying Canvas LMS courses, assignments, and grades. Enables natural language interaction with Canvas data via MCP clients like Claude Desktop.
Updated 8 months ago (2026-01-11 07:23 UTC)
19
MIT
canvas-lms
Education & Learning Tools Content Management Systems
Drastixs
A
license
Not graded
quality
D
maintenance
MCP server for Canvas LMS with automatic OAuth authentication. Enables interaction with courses, assignments, grades, modules, discussions, quizzes, files, calendar, messaging, and more without manual API token management.
Updated 5 months ago (2026-04-05 16:16 UTC)
159
MIT
Canvas MCP Connector
Education & Learning Tools
JaeYu-Dev
A
license
B
quality
C
maintenance
A read-only MCP server for Canvas LMS that exposes a user's courses, upcoming work, and assignments as callable tools.
Updated 25 days ago (2026-08-12 07:45 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/admin978/canvas-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Canvas LMS MCP Server (canvas-mcp)

Who this is for

What you can ask Claude

Quick start

1) Create a Canvas personal access token

2) Install

3) Configure ~/.canvas.env

4) Register in your MCP client

Tools exposed

Bulk dump

Local-first, privacy and token flow

Demo

Try these prompts

Development

Publishing a new release

1. Bump the version everywhere

2. Merge the PR into main

3. Publish canvas-local-mcp to PyPI

4. Create and push the tag vX.Y.Z

5. Verify

Contributing, roadmap and support

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Canvas LMS MCP Server (`canvas-mcp`)

3) Configure `~/.canvas.env`

2. Merge the PR into `main`

3. Publish `canvas-local-mcp` to PyPI

4. Create and push the tag `vX.Y.Z`